[Python-Dev] PEP 557: Data Classes (original) (raw)

Nathaniel Smith njs at pobox.com
Mon Sep 11 12:34:53 EDT 2017

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:

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.

But wouldn't this just be field(cmp=False), no need to fiddle with hash=?

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.

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 :-).

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

More information about the Python-Dev mailing list