3 ms·

Good writeup. A couple points. `zope.interface` is more explicit and scalable than `typing.Protocol`s, and more flexible than `abc.ABC`. There's a mypy plugin

Good writeup. A couple points. `zope.interface` is more explicit and scalable than `typing.Protocol`s, and more flexible than `abc.ABC`. There's a mypy plugin for it: https://github.com/Shoobx/mypy-zope https://github.com/Shoobx/mypy-zope > The drawback is that code that changes the representation of its data a lot tends not to be fast code. That's not a very convincing reason to avoid dataclasses except in the most performance-constrained environments -- and even then I'm doubtful it'd help. Especially with `slots=True`, dataclasses can take less resources.

deleted 7y ago
[deleted]
duckerude 7y ago
> Especially with `slots=True`, dataclasses can take less resources. `slots=True` doesn't exist, though there's an experimental implementation at https://github.com/ericvsmith/dataclasses/blob/master/dataclass_tools.py https://github.com/ericvsmith/dataclasses/blob/master/datacl... . The main issue is that slots have to exist at class definition, and @dataclass takes an already defined class, so you'd have to create a clone of the class, which is nasty. On top of that you can't always add __slots__ manually, because it conflicts with default field values (and field()s). __slots__ wants to add a descriptor as a class attribute but it can't do that if the default value is already an attribute.
- calpaterson 7y ago
  The GP is probably referring to the attrs library, which is another (older) way of creating dataclasses than the stdlib way. It has an easy way to create slotted dataclasses. http://www.attrs.org/en/stable/examples.html#slots http://www.attrs.org/en/stable/examples.html#slots
calpaterson 7y ago
(Hi, author of article here) I'm glad you liked the article :) Interesting tip on zope.interface - hadn't heard of that and will be looking into it > > The drawback is that code that changes the representation of its data a lot tends not to be fast code. > That's not a very convincing reason to avoid dataclasses except in the most performance-constrained environments -- and even then I'm doubtful it'd help. Especially with `slots=True`, dataclasses can take less resources. re this - slotted (data)classes are useful when you want to reduce peak memory usage but don't help with the problem of programs that instantiate (and teardown) objects excessively. IME this is a common pitfall that slows down Python programs (often by a couple of orders of magnitude) and contributes to an unjustified perception that Python is "too slow". The "excessive changes in data representation" anti-pattern is slow in every language but because the syntactic/correctness overhead of creating a mass of objects is higher in (eg) C than Python the arises much less often. My worry is that as the syntactic burden of this is lowered even further it becomes even more common. The problem is so severe in the Java community that it has had a huge influence on JVM design. I haven't kept up with every development in the JVM but last I was using it (maybe 6 years ago) it already had a huge number of techniques to reduce the burden of frequent object creation. CPython of course doesn't have any of these tricks.

deleted 7y ago

[deleted]

duckerude 7y ago

> Especially with `slots=True`, dataclasses can take less resources. `slots=True` doesn't exist, though there's an experimental implementation at https://github.com/ericvsmith/dataclasses/blob/master/dataclass_tools.py https://github.com/ericvsmith/dataclasses/blob/master/datacl... . The main issue is that slots have to exist at class definition, and @dataclass takes an already defined class, so you'd have to create a clone of the class, which is nasty. On top of that you can't always add __slots__ manually, because it conflicts with default field values (and field()s). __slots__ wants to add a descriptor as a class attribute but it can't do that if the default value is already an attribute.

calpaterson 7y ago
The GP is probably referring to the attrs library, which is another (older) way of creating dataclasses than the stdlib way. It has an easy way to create slotted dataclasses. http://www.attrs.org/en/stable/examples.html#slots http://www.attrs.org/en/stable/examples.html#slots

calpaterson 7y ago

(Hi, author of article here) I'm glad you liked the article :) Interesting tip on zope.interface - hadn't heard of that and will be looking into it > > The drawback is that code that changes the representation of its data a lot tends not to be fast code. > That's not a very convincing reason to avoid dataclasses except in the most performance-constrained environments -- and even then I'm doubtful it'd help. Especially with `slots=True`, dataclasses can take less resources. re this - slotted (data)classes are useful when you want to reduce peak memory usage but don't help with the problem of programs that instantiate (and teardown) objects excessively. IME this is a common pitfall that slows down Python programs (often by a couple of orders of magnitude) and contributes to an unjustified perception that Python is "too slow". The "excessive changes in data representation" anti-pattern is slow in every language but because the syntactic/correctness overhead of creating a mass of objects is higher in (eg) C than Python the arises much less often. My worry is that as the syntactic burden of this is lowered even further it becomes even more common. The problem is so severe in the Java community that it has had a huge influence on JVM design. I haven't kept up with every development in the JVM but last I was using it (maybe 6 years ago) it already had a huge number of techniques to reduce the burden of frequent object creation. CPython of course doesn't have any of these tricks.