
Guide to Data Classes in Python 3.7 - dbader
https://realpython.com/python-data-classes/
======
tedmiston
Data Classes are a cool feature, useful, and a superior alternative to
namedtuple.

But while this was brewing, attrs ate their lunch. Data Classes just don't go
far enough compared to what attrs [1] has provided for a while now. If there's
a compelling reason to switch, I haven't found it yet.

Can I use Data Classes in a library supporting Python 2.7, 3.4-3.7? I don't
think the answer is yes today.

[1]: [https://github.com/python-attrs/attrs](https://github.com/python-
attrs/attrs)

~~~
Rotareti
> Data Classes are a cool feature, useful, and a superior alternative to
> namedtuple.

I'm curious, how is it "superior" to NamedTuples?

~~~
bb88
The PEP lists the rationale and some discussion.

[https://www.python.org/dev/peps/pep-0557/#rationale](https://www.python.org/dev/peps/pep-0557/#rationale)
[https://www.python.org/dev/peps/pep-0557/#id10](https://www.python.org/dev/peps/pep-0557/#id10)

------
lunchladydoris
I haven't watched it yet but I saw that Raymond Hettinger presented on data
classes at PyCon last week [0].

[0]:
[https://www.youtube.com/watch?v=T-TwcmT6Rcw](https://www.youtube.com/watch?v=T-TwcmT6Rcw)

~~~
neuland
I thought it was pretty good. He focused mostly on why you'd use this over
typing.NamedTuple or hand-rolled code. Then, he talks about the couple
limitations and where it'll go in the future.

------
hprotagonist
I am happy that lightweight data classes are now in the stdlib -- hopefully
this puts an expiration date on overuse of namedtuple, which has turned out to
be kind of a bad idea. Being able to make sane lightweight classes in one-off
one-file python scripts will be nice.

That said, on any package that I write that has third party dependencies
anyway (read: all of them), I don't see a compelling reason to change from
attrs.

~~~
dfee
You nailed it with "on any package that I write that has third party
dependencies anyway". On my recent package I was going for zero dependencies
(at py3.7+) so I used the backport of dataclasses.

Ultimately, I threw out dataclasses too. But if I didn't need __repr__,
__post_init__ and __slots__ with default values, I'd probably have just stuck
with dataclasses :)

------
dfee
The problem with dataclasses are:

1) they don’t support __slots__ and default values

2) type hints aren’t supported yet, and it doesn’t appear they’ll be added to
the 3.6 backport

The former issue will be resolved (maybe in 3.8?) but it will require either a
metaclass approach or the @dataclass decorator to build a separate class.

The good news is that dataclasses (the backport) work on PyPy 6.0.0.

~~~
sologoub
On the __slots__, the article claims that these do:
[https://realpython.com/python-data-classes/#optimizing-
data-...](https://realpython.com/python-data-classes/#optimizing-data-classes)

EDIT: From PEP 557: [https://www.python.org/dev/peps/pep-0557/#support-for-
automa...](https://www.python.org/dev/peps/pep-0557/#support-for-
automatically-setting-slots)

“Support for automatically setting __slots__?

At least for the initial release, __slots__ will not be supported. __slots__
needs to be added at class creation time. The Data Class decorator is called
after the class is created, so in order to add __slots__ the decorator would
have to create a new class, set __slots__, and return it. Because this
behavior is somewhat surprising, the initial version of Data Classes will not
support automatically setting __slots__. There are a number of workarounds:

\- Manually add __slots__ in the class definition.

\- Write a function (which could be used as a decorator) that inspects the
class using fields() and creates a new class with __slots__ set.”

~~~
dfee
The article doesn't discuss slots and default values. Here's the actual
reference implementation for dataclasses where it's discussed:
[https://github.com/ericvsmith/dataclasses/issues/28](https://github.com/ericvsmith/dataclasses/issues/28)

Your second solution works fine (and is what I'd referenced). For your first
solution, I'd again redirect you to my statement "they don’t support __slots__
and default values" and the above link.

~~~
sologoub
It’s not my solution, just a direct quote from PEP.

------
jwilk
Another alternative to data classes is types.SimpleNamespace, available since
Python 3.3:

[https://docs.python.org/3/library/types.html#types.SimpleNam...](https://docs.python.org/3/library/types.html#types.SimpleNamespace)

------
sologoub
Data classes was an interesting read and will definitely save some time in the
future, but I think the __slots__ mention is where I got the most value from
(big memory and access speed savings!).

Additional reading on __slots__:
[https://stackoverflow.com/questions/472000/usage-of-
slots](https://stackoverflow.com/questions/472000/usage-of-slots)

------
talltimtom
This marks the beginning of the end for python as a dynamic language.

------
mistrial9
Python keeps evolving -- great ! and also, consider support for a _stable_
Python 2.7 LTS .. you know, for more than five years from now?

~~~
rspeer
Python 2.7 has been stable and supported for almost 8 years -- how much more
long term do you want? Even releases of Java only seem to get about 6 years of
support.

~~~
coldtea
> _Python 2.7 has been stable and supported for almost 8 years -- how much
> more long term do you want?_

Forever? 2.x codebase are in the millions of lines of code in companies, and
they won't be converted or go away anytime soon. And those will need security
updates and bug fixes.

Note that Google and Dropbox are still running tons of Python 2.x -- and those
are two companies where Guido Vas Rossum himself has worked in the last 10
years.

Not consider the average company with tons of Python 2.x code. It's not going
anywhere soon.

Heck, why is everyone surprised by this? Or is it just 20 year old first time
pro devs that are surprised? The world still supports tons of Cobol and other
"old" language code -- some running for 3-4 decades after a language went "out
of fashion"...

~~~
sametmax
> Forever?

You can have support forever.

You just can't have it __for free__ forever.

There are companies out there that will happily sell you the service.

You already get an amazing tech for free, and support of 2 decades in you take
all the 2.X branch in consideration (e.g: 4 times the ubuntu LTS). You
complaining at this point is just insulting the community.

I find it infuriating. When the JS or Ruby community breaks stuff, they give a
few weeks notice, and a few months to migrate. Nobody complains. Python give
10 years, a lot of tooling and tutorials, and some people keep complaining.
This is where being too nice is a problem.

In 2020, I'll triple my price for any work on 2.7. I'm done being fair to
people with such ingratitude.

~~~
coldtea
> _In 2020, I 'll triple my price for any work on 2.7. I'm done being fair to
> people with such ingratitude._

This doesn't make any sense. You're not running a charity. If you can get
customers with the tripled price, then do triple it. If you can get customers
with a 100x price, you'd be a fool not to 100x your price.

If, on the other hand, you can't get customers for triple the price, then
tripling it will just make people go to someone else. You're not hurting
anybody either way...

~~~
sametmax
> This doesn't make any sense. You're not running a charity. If you can get
> customers with the tripled price, then do triple it. If you can get
> customers with a 100x price, you'd be a fool not to 100x your price

You say that because you see business as only a gateway to make money. But if
you work in the libre community, you'll see that ethics and promotion of the
libre is a very important part of it. It's also why FOSS people make less
money.

~~~
coldtea
> _But if you work in the libre community, you 'll see that ethics and
> promotion of the libre is a very important part of it_

For how many people? Most major FOSS people I know work in large companies
from Red Hat to IBM and Joyent. Heck, speaking of Python, Guido worked for
Google and Dropbox.

And most of the others are volunteers.

Besides, I wouldn't call "tripling the price" when you don't like the client
using an older version exactly "ethical".

Have you talked to the client? Do you know their costs and externalities for a
2.7 -> 3 rewrite of their existing (and working code)? It's not like they are
capricious and want to use 2.7 out of malice.

