[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Is static typing still optional?

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?