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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
