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.

Huh, it's the other way around for me. Just about every nontrivial Python project I write requires at least one third-party library, and one much more complicated than attrs at that, that I may as well use attrs too. All the complexity of having dependencies - both distributing them / setting up a virtualenv / etc., and whatever scrutiny I wish to do on dependencies - have a pretty big constant term from doing them at all; doing them for one more dependency (and one that doesn't change all that often) is only a bit more work.

Granted, I'm not reviewing my third-party dependencies line by line when I upgrade them. But also I'm more afraid of the security risks of large amounts of in-house code that aren't exposed to public scrutiny, and so a policy that dissuaded the use of even high-quality and well-regarded third-party dependencies seems like it would do more harm than good.

Besides that, it helps that I happen to have met the maintainer of attrs at PyCon (and attrs has only one uploader in PyPI), and therefore I'm less concerned about supply-chain attacks against it, whether of the malicious-maintainer variety or the maintaner-got-scammed-or-hacked variety, than, again, most of my other dependencies whose maintainers I've never heard of. I'm not sure this scales particularly well, but I do feel like there's still something in the open source community being a community.

Not that attrs or dataclasses has particularly significant attack surface, but when considering stdlib vs. 3rd-party you also have to consider the amount of maintenance and the release cadence. Attrs can release every few months if the rate of change demands it, whereas the stdlib has a fixed yearly release schedule that is tied to interpreter versions. Attrs has a small, focused development team whereas the stdlib is maintained by developers who are stretched very thin, and many packages within it are effectively abandoned. Upgrading dataclasses means upgrading everything in the stdlib at the same time, whereas attrs can be upgraded independently, by itself.

Supply chain attacks are a complex and nuanced topic so there are plenty of reasons to be thoughtful about adopting new dependencies, but it's definitely not as simple as "just use the stdlib for everything".

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?

Honestly, only use python because I have to. I don't think it belongs inside a decently sized software product

Others disagree, though, so I must use it

What you're saying only bolsters my opinion

Raymond Hettinger’s (perhaps biased) take on dataclasses vs attrs:

https://m.youtube.com/watch?v=T-TwcmT6Rcw

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

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.

Key thing for me was the ability to add type hinting

Namedtuples also behave like tuples, which is great when you want to incrementally turn tuples into classes but if you want an easy way of creating classes, it's probably not a good idea to have them behave like tuples. Plus dataclasses have more features.

There’s also the fact that sometimes you need an actual tuple - in some places (C extensions like numpy, opencv, …) and a dataclass just doesn’t work.

From a users perspective data classes look kind of like a C struct and in particular include type annotations so fit well with type checkers. They also allow for default values and give more control over generating equality, hash, string and initialisation methods.

Comparatively named tuples are an older language feature which essentially allow you to define named accessors for tuple elements. IIRC, these days you can also define type annotations for them.

Their use case essentially overlap. Personally I much prefer data classes.

FWIW, you can also add type annotations for namedtuples, with a syntax similar to data classes: https://docs.python.org/3/library/typing.html#typing.NamedTu...

You can even type dictionaries this way: https://docs.python.org/3/library/typing.html#typing.TypedDi...

This is my confusion learning python, just pick a thing for struct will ya :)

counterpoint: stdlib is where things go to die

dataclasses also have the slots kwargs since 3.10. Should help with faster access and memory

attrs is a superset of dataclasses.