On 9/11/2017 12:34 PM, Nathaniel Smith wrote: > On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith <eric at 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 at 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 >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4