RetroSearch Browse

Tue Feb 6 22:33:45 EST 2018 · https://mail.python.org/pipermail/python-dev/2018-February/152162.html

On 02/06/2018 06:48 PM, Guido van Rossum wrote:

> That seems a rare case (though I hadn't thought of it). I had thought of the use case where you want a frozen type
> without a hash; that you can presumably implement using
>
> def __hash__(self): raise TypeError("not hashable")
>
> We can do a similar thing to preserve the superclass __hash__ if it's rare enough:
>
> def __hash__(self): return super().__hash__()
>
> If at all possible I'd like to kill the tri-state hash= flag -- the amount of time spent creating and discussing the
> huge table in the bpo issue are an indication of how much effort it would take other people to understand it.

I think the biggest reason this has become so complicated is because we are refusing to use an Enum:

class Hashable(Enum):
     IF_SAFE = 1
     ADD = 2
     DEFER = 3
     NONE = 4

IF_SAFE is currently the False value.
ADD is currently the True value
DEFER means don't add one
NONE means set __hash__ to None

The only thing missing now is a setting to indicate that dataclass should do nothing if the class already has a __hash__ 
method -- possibly DEFER, although I think IF_SAFE can include "the class already has one, it's not safe to override it".

> If either of those use cases becomes annoyingly common we'll have to think of something else.

Or we could solve it now and not have to deal with backwards-compatibility issues in the future.

--
~Ethan~

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-February/152162.html below:

[Python-Dev] Dataclasses and correct hashability