You'd have to expand more on your proposal for using a dictionary for people to be able to reply. The article was full of use cases, so why not address those rather than simply state that you can't think of any?

When you say use a dictionary, do you mean subclass `dict`? One of the aims of the project is to constrain the available instance attributes, as in a normal class. How would your dict proposal do that?

In that case, I'd just deal with the overhead of a normal class. More boilerplate, of course, but I'd have more control over the class.

As to the use cases, I was not really buying into them other than the nice destructuring example, which is actually very nice one.

I think the point is that this is basically a normal class, but one with the boilerplate already written for you. If you don't mind boilerplate, this library does nothing for you. If you don't want to write classes and think dicts are good enough, this library does nothing for you.

If you do want to have classes but don't want the boilerplate that comes with making a basic-but-full-featured class, then that's where this library comes in.

Dictionaries are not for fixed fields.

if you have a dict, it maps something to something else. You should be able to add and remove values.

Objects, on the other hand, are supposed to have specific fields of specific types, because their methods have strong expectations of what those fields and types are.

attrs lets you be specific about those expectations; a dictionary does not. It gives you a named entity (the class) in your code, which lets you explain in other places whether you take a parameter of that class or return a value of that class.

A class with more methods than the Point3d example.