On 1/29/2018 4:01 AM, Raymond Hettinger wrote:
On Jan 28, 2018, at 11:52 PM, Eric V. Smith <e...@trueblade.com> wrote:
I think it would be a bad design to have to opt-in to hashability if using
frozen=True.
I respect that you see it that way, but it doesn't make sense to me. You can
have either one without the other. It seems to me that it is clearer and more
explicit to just say what you want rather than having implicit logic guess at
what you meant. Otherwise, when something goes wrong, it is difficult to debug.
I certainly respect your insights.
The tooltips for the dataclass decorator are essentially of checklist of
features that can be turned on or off. That list of features is mostly
easy-to-use except for hash=None which has three possible values, only one of
which is self-evident.
Which is the one that's self-evident? I would think hash=False, correct?
The problem is that for repr=, eq=, compare=, you're saying "do or don't
add this/these methods, or if true, don't even add it if it's already
defined". The same is true for hash=True/False, with the complication
of the implicit __hash__ that's added by __eq__.
In addition to "do or don't add __hash__", there needs to be a way of
setting __hash__=None.
The processing of hash=None is trying to guess what sort of __hash__ you
want: not set it and just inherit it, generate it based on fields, or
set it to None. And if it guesses wrong, based on the fairly simple
hash=None rules, you can control it with other values of hash=. Maybe
that's the problem.
I'm open to ways to express these options. Again, I think losing "do the
right thing most of the time without explicitly setting hash=" would be
a shame, but not the end of the world.
And changing it to "hashable=" isn't quite as simple as it seems, since
there's more than one definition of hashable: identity-based or field-based.
We haven't had much in the way of user testing, so it is a significant data
point that one of your first users (me) found was confounded by this API. I
recommend putting various correct and incorrect examples in front of other
users (preferably experienced Python programmers) and asking them to predict
what the code does based on the source code.
I agree it's sub-optimal, but it's a complex issue. What would the
interface look like that allowed a programmer to know if an object was
hashable based on object identity versus field values?
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
