4 ms·
Using dataclass for all basic state classes whose primary purpose is public state with sensible init makes sense. But for the many other purposes of classes tha
by kodablah 4y ago
Using dataclass for all basic state classes whose primary purpose is public state with sensible init makes sense. But for the many other purposes of classes that need custom init, advanced field defaults, no equality, custom repr/str, advanced inheritance, etc dataclasses give you nothing but a bunch of magic to turn off or work around.
Whether you're using Kotlin data class, a C# record, a Scala case class, or whatever, we've seen in practice that these are only good for (often immutable) public state and data composition. Business objects with more logic and more than simple state/member manipulation are only hampered by dataclass field approaches. If Python embraced immutability and composition more at its core, then using dataclasses in these cases would make more sense.
- dec0dedab0de 4y agoThat was similar to my initial reaction, but after trying some things in another comment I'm kind of sold on dataclasses. As long as it raised a syntax error if a class combined __init__ with arg: type, then I think you can still do everything else you would in a normal class. It's just a shortcut for when that's all you need.
- zzzeek 4y ago> But for the many other purposes of classes that need custom init, write your own `__init__` method then, as you would anyway. Dataclass' default init is way better than that of `object`. > advanced field defaults same > no equality set eq=False, all dataclass methods are optional > custom repr/str write __repr__ and __str__ methods, same as init, dataclass' default is much nicer than that of `object` > advanced inheritance What's the issue with inheritance? what's "advanced" inheritance, you mean mixins? > etc dataclasses give you nothing but a bunch of magic to turn off or work around. Python `object` has all kinds of default behaviors too, which are just worse. default behaviors aren't "magic". dataclasses currently manufactures its methods at runtime, so that's maybe "magic", but all of that could be built into Python, then it would just be, "default behavior".
- PartiallyTyped 4y agoRe __init__ and advanced defaults, these may be achieved/set using __post_init__.
- athorax 4y agoFor awhile inheritance with dataclasses was fairly broken. They added kw_only in 3.10 which definitely helped. Even outside of dataclasses, python's MRO can be a footgun with multiple inheritance This video has some good explanations of inheritance behavior in python https://www.youtube.com/watch?v=X1PQ7zzltz4 https://www.youtube.com/watch?v=X1PQ7zzltz4
- insanitybit 4y ago> dataclasses give you nothing but a bunch of magic to turn off or work around. I don't think anything is particularly magical. At most you have a `blah=False` or you just override the thing manually and the decorator 'just works'. Maybe some really insane inheritance stuff? IDK I haven't run into any case where I didn't end up wanting `@dataclass`