Python keeps evolving -- great ! and also, consider support for a stable Python 2.7 LTS .. you know, for more than five years from now?
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.
Guide to Data Classes in Python 3.7
11–20 of 48 posts
Re: Guide to Data Classes in Python 3.7
#12I 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 a…
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 :)
Re: Guide to Data Classes in Python 3.7
#13Python keeps evolving -- great ! and also, consider support for a stable Python 2.7 LTS .. you know, for more than five years from now?
Python is maintained by volunteers. Providing support for more than 10 years is more than enough in my opinion. The community has moved on to 3, but I'm sure there will be companies doing consulting and fixing 2.x bugs for a fee.
Re: Guide to Data Classes in Python 3.7
#14But 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.
Re: Guide to Data Classes in Python 3.7
#15Re: Guide to Data Classes in Python 3.7
#16Python keeps evolving -- great ! and also, consider support for a stable Python 2.7 LTS .. you know, for more than five years from now?
Python 3.3 has been available since 2012. 2020 was already a deadline that had been pushed back at least once for 2.x. I understand volatility, but 5+ years in the software world is an eternity.
Re: Guide to Data Classes in Python 3.7
#17Data 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://githu…
Meanwhile, I was not a user of attrs before, rather I used collections.namedtuple and then typing.NamedTuple. So, data classes is a win for me and other people like me who weren't using attrs. And you can continue to use attrs without being bothered at all.
In Raymond Hettinger's talk [0] at PyCon 2018, he even says that more features from attrs will likely get added, such as data validation [1]. And that his talk was the one chance for the developer (Eric Smith) to get praise, because everyone is going to instantly second guess every decision he made.
[0] https://www.youtube.com/watch?v=T-TwcmT6Rcw
[1] see 42:36 on future directions
Re: Guide to Data Classes in Python 3.7
#18I 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
Re: Guide to Data Classes in Python 3.7
#19Data 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://githu…
I'm curious, how is it "superior" to NamedTuples?
Re: Guide to Data Classes in Python 3.7
#20Python keeps evolving -- great ! and also, consider support for a stable Python 2.7 LTS .. you know, for more than five years from now?
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.
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"...