[Python-Dev] PEP 557: Data Classes

[Eric V. Smith]

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
>