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.
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.