[Python-Dev] PEP 557: Data Classes

[Eric V. Smith]

On 9/10/17 11:08 PM, Nathaniel Smith wrote:
> Hi Eric,
>
> A few quick comments:
>
> Why do you even have a hash= argument on individual fields? For the
> whole class, I can imagine you might want to explicitly mark a whole
> class as unhashable, but it seems like the only thing you can do with
> the field-level hash= argument is to create a class where the __hash__
> and __eq__ take different fields into account, and why would you ever
> want that?

The use case is that you have a cache, or something similar, that 
doesn't affect the object identity.

> Though honestly I can see a reasonable argument for removing the
> class-level hash= option too. And even if you keep it you might want to
> error on some truly nonsensical options like defining __hash__ without
> __eq__. (Also watch out that Python's usual rule about defining __eq__
> blocking the inheritance of __hash__ does not kick in if __eq__ is added
> after the class is created.)
>
> I've sometimes wished that attrs let me control whether it generated
> equality methods (eq/ne/hash) separately from ordering methods
> (lt/gt/...). Maybe the cmp= argument should take an enum with options
> none/equality-only/full?

Yeah, I've thought about this, too. But I don't have any use case in 
mind, and if it hasn't come up with attrs, then I'm reluctant to break 
new ground here.

> The "why not attrs" section kind of reads like "because it's too popular
> and useful"?

I'll add some words to that section, probably focused on typing 
compatibility. My general feeling is that attrs has some great design 
decisions, but goes a little too far (e.g., conversions, validations). 
As with most things we add, I'm trying to be as minimalist as possible, 
while still being widely useful and allowing 3rd party extensions and 
future features.

Eric.