3 ms·

This seems nice, but other than easy destructuring of functions that return long tuples (which really should return dicts), I cannot figure out a good use case

This seems nice, but other than easy destructuring of functions that return long tuples (which really should return dicts), I cannot figure out a good use case for it over using a dictionary. I am keen to hear others' opinions.

maxerickson 10y ago
A class with more methods than the Point3d example.
Myrmornis 10y ago
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?
- jgalt212 10y ago
  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.
  - chc 10y ago
    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.
glyph 10y ago
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.

maxerickson 10y ago

A class with more methods than the Point3d example.

Myrmornis 10y ago

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?

jgalt212 10y ago
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.
- chc 10y ago
  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.

glyph 10y ago

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.