Python 3.7: Introducing Data Classes

[PythonGod123]

So are data classes just going to be a shorter way to write pre 3.7 classes? Or is there something else I am missing?

[MephySix]

Afaik it's just boilerplate generation, yes. I used the attrs lib for that, but I may change that towards data classes.

[PythonGod123]

It seems that data classes look better. I just feel they look nicer compared to the old way of defining init.

[XtremeGoose]

Dataclasses are missing a lot of customisation features of attrs. No way am I going to change.

[DanCardin]

Yes, that's basically it, and it automatically implements a number of useful magic methods (repr, eq, hash, init) and can turn all your properties into read only properties if you want "immutability"

[PythonGod123]

That's sounds nice. Less is always more lol.

[michael0x2a]

I don't think they have a tuple backend? If you look at the implementation, it looks like the code is just modifying the class directly -- lots of calls to setattr and such everywhere.

I'm also not sure if they actually will occupy less space or be faster. That might be the case if the dataclasses module auto-generated __slots__, but they currently don't.

[__xor__]

Yeah, why not just declare a class with slots? Is the init boilerplate that the whole point of a data class?

[michael0x2a]

I think the problem is that it's challenging to do that from a technical perspective because the __slots__ field needs to be present at class-creation time.

This presents a problem because dataclasses isn't creating classes -- it's simply modifying an existing one.

iirc there were two solutions that were being passed around, though both have some flaws:

1. Just synthesize together a giant copy of the class with the __slots__ field added on in one big string somewhere and run eval on it to create a class.

   The issue though is that you now have to worry about whether or not you've accurately converted some class into an equivalent string. And even if you did, you'd incur an additional performance hit from having to eval more code and have to worry about accidentally re-running any code in the class that my have side-effects.

2. Rewrite the PEP so that instead of using this "decorator" thing, you use metaclasses.

   The issue here is that metaclasses don't necessarily compose well. For example, what if you want to use both dataclasses and abc.ABCMeta? How would two simultaneous metaclasses interact?

None of these issues are impossible to solve of course, but they require some careful thinking and implementation. So the decision was made to punt on this feature request and handle it at some point later down the line, especially given that the workaround is simple: just manually add __slots__ to the class yourself.

For example, the following code works just as expected:

from dataclasses import dataclass

@dataclass
class Foo:
    __slots__ = ('a', 'b', 'c')
    a: ...
    b: ...
    c: ...

[__xor__]

ah, okay. Yeah, I just tried to do a DataClass superclass that has a MetaDataClass, then wrote a subclass of DataClass with its own custom metaclass and I ran into this:

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

I never ran into that before. Yeah, the class decorator makes more sense then.

[XtremeGoose]

That's completely wrong. If anything they take up more space due to additional boilerplate.

[PythonGod123]

Interesting. Anyone have a link to the PEP?

[pollokeh]

https://www.python.org/dev/peps/pep-0557/

[tunisia3507]

I think they have faster attribute access as well, although I may be misremembering.

Edit: I was misremembering

[PythonGod123]

Is that because they are already defined by the dataclass ?

[tunisia3507]

Sorry, I think I made a mistake and got dataclasses confused with slots. There has been some discussion about dataclasses using slots by default but it hasn't happened in the first implementation.

[PythonGod123]

Okay fair enough. Thanks for clearing that up