On 9/11/2017 12:34 PM, Nathaniel Smith wrote:
On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith <e...@trueblade.com> wrote:
On 9/10/17 11:08 PM, Nathaniel Smith wrote:
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.
But wouldn't this just be field(cmp=False), no need to fiddle with hash=?
Ah, true. You're right, I can't see any good use for setting hash on a
field that isn't already controlled by cmp. I think field level hash can go.
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.)
At the class level, I think it makes more sense. But I'll write up some
motivating examples.
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.
https://github.com/python-attrs/attrs/issues/170
From that thread, it feels like part of the problem is that it's
awkward to encode this using only boolean arguments, but they're sort
of stuck with that for backcompat with how they originally defined
cmp=, hence my suggestion to consider making it an enum from the start
:-).
I'll respond to other emails about this, probably tomorrow.
Eric.
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.
If the question is "given that we're going to add something to the
stdlib, why shouldn't that thing be attrs?" then I guess it's
sufficient to say "because the attrs developers didn't want it". But I
think the PEP should also address the question "why are we adding
something to the stdlib, instead of just recommending people install
attrs".
-n
_______________________________________________
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/eric%2Ba-python-dev%40trueblade.com
_______________________________________________
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
