[Python-Dev] Is static typing still optional? (original) (raw)

Eric V. Smith eric at trueblade.com
Mon Jan 29 08:13:29 EST 2018

On 1/29/2018 4:01 AM, Raymond Hettinger wrote:

On Jan 28, 2018, at 11:52 PM, Eric V. Smith <eric at 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.

More information about the Python-Dev mailing list