see also "dataclasses" since python 3.7
counterpoint: stdlib is where things go to die
Attrs – the Python library everyone needs (2016)
31–40 of 115 posts
Re: Attrs – the Python library everyone needs (2016)
#32see also "dataclasses" since python 3.7
Raymond Hettinger’s (perhaps biased) take on dataclasses vs attrs:
Re: Attrs – the Python library everyone needs (2016)
#33Someone should tell this person about dataclasses
dataclasses was explicitly inspired by attrs. https://github.com/ericvsmith/dataclasses/issues/1
Re: Attrs – the Python library everyone needs (2016)
#34Earlier quoted context omitted.
Not a python guy, so confused as to why a thing called namedtuple behaves like dataclasses, what are their different usecases?
Named tuples have been around for a long time (since 2.6), whereas dataclasses are a relatively recent addition to the standard library (3.7). Their differences are highlighted in the dataclasses PEP: https://www.python.org/dev/peps/pep-0557/#why-not-just-use-n...
looks like the key thing is immutability
Re: Attrs – the Python library everyone needs (2016)
#35Earlier quoted context omitted.
Named tuples have been around for a long time (since 2.6), whereas dataclasses are a relatively recent addition to the standard library (3.7). Their differences are highlighted in the dataclasses PEP: https://www.python.org/dev/peps/pep-0557/#why-not-just-use-n...
looks like the key thing is immutability
To clarify, both named tuples and dataclasses can be immutable (the former are always immutable and the latter can be made immutable with `frozen=True`).
There is no way, however, to make a named tuple mutable.
Re: Attrs – the Python library everyone needs (2016)
#36Someone should tell this person about dataclasses
Attrs was mentioned in the PEP [0] for dataclasses.
[0] https://www.python.org/dev/peps/pep-0557/#why-not-just-use-a...
Re: Attrs – the Python library everyone needs (2016)
#37Someone should tell this person about dataclasses
I started a project with dataclasses and quickly ran into their limitations (which are by design) and migrated to attrs. It's quite a bit better.
If you take 10 seconds to read attrs website they do go over the differences and maybe discussing those would be more valuable than some cheap snark.
Re: Attrs – the Python library everyone needs (2016)
#38Earlier quoted context omitted.
We always used attrs with the runtime type validators anyway. Getting those types checked in Python was way more valuable to my teams than the minor boilerplate reduction. If you’re worried about the performance hit of extra crap happening at runtime… dear lord use another programming language. Dataclasses is just… meh. Pydantic and Attrs just have so many great features, I would never use dataclasses unless someone…
Thanks. You do make a lot of good points. Attrs just has the features I need for now. It certainly feel a touch verbose but I’m happy to pay the price.
can you tell me which parts feel verbose? In my recent usage, I've not found myself using the older, more verbose approaches.
Re: Attrs – the Python library everyone needs (2016)
#39For anyone interested in differences between attrs and pydantic, how to use dataclasses, etc. I can't recommend the mCoding channel enough, this video : https://www.youtube.com/watch?v=vCLetdhswMg goes into the different libraries and there are other videos going more in depth on how to use them.
Re: Attrs – the Python library everyone needs (2016)
#40Earlier quoted context omitted.
Came here to say this, dataclasses have been super helpful for a big part of the pain point highlighted by the author. More often than not, that is enough for me.
Yes. There needs to be a very good reason for me to pull in a third party library (in this day and age, given supply chain attacks, etc.). I don’t see what Attrs gives me that dataclasses does not.
Python's STL is such that using it is a code smell. It's better to just use the right tool for the job: you are almost guaranteed to need at least one external library/module for any project of even moderate complexity. So bite the bullet, invest in the time/tooling to do packaging correctly, and use the very excellent Python ecosystem (isn't it why you are using Python to begin with?) that you have at your disposal.
Sticking with the "rusty, leaking batteries included!" in the STL is a bad call and I don't believe it is safe, either; most of the STL is abandonware that is just being shipped for backward compatibility sake. Don't make future product decisions, design decisions etc. based on Python teams' deprecation requirements!
I've been writing Python a long time and have grown quite frustrated by some of its warts. But every time I look at seriously investing in another language attrs is one of the few things I wouldn't want to give up. It's not perfect but I'll take very, very good when I can get it, yeah?