See https://mail.python.org/pipermail/python-dev/2018-February/152150.html for a discussion. This will remove the @dataclass hash= tri-state parameter, and replace it with an unsafe_hash= boolean-only parameter. From that thread: """ I propose that with @dataclass(unsafe_hash=False) (the default), a __hash__ method is added when the following conditions are true: - frozen=True (not the default) - compare=True (the default) - no __hash__ method is defined in the class If we instead use @dataclass(unsafe_hash=True), a __hash__ will be added regardless of the other flags, but if a __hash__ method is present, an exception is raised. Other values (e.g. unsafe_hash=None) are illegal for this flag. """

This is a truly awful name, there's nothing unsafe about the hash parameter. We rightly hesitate to label *actual* unsafe functions, like eval and exec, with that name. Are we committed to this name?

That's a quote from Guido. There weren't any better ideas on the python-dev thread.

It is important to convey the idea that if you are thinking of using this you are probably doing something fishy. An alternative could be `_hash`, which at least indicates it is not for general use, like `sys._getframe()`.

Note that this class (from the test suite) will now raise an exception: @dataclass(unsafe_hash=True) class C: i: int def __eq__(self, other): return self.i == other.i That's because it has a __hash__, added when __eq__ is defined. I think we're better off with the rule being: If unsafe_hash=True, raise an exception if __hash__ exists and is not None. Otherwise add __hash__. That's how it used to be with hash=True (in 3.70b1). Or is that what you meant by "but if a __hash__ method is present, an exception is raised"? Notice the word "method", instead of attribute.

Sorry, I used imprecise language. What you propose is fine. On Feb 24, 2018 09:54, "Eric V. Smith" <report@bugs.python.org> wrote: > > Eric V. Smith <eric@trueblade.com> added the comment: > > Note that this class (from the test suite) will now raise an exception: > > @dataclass(unsafe_hash=True) > class C: > i: int > def __eq__(self, other): > return self.i == other.i > > That's because it has a __hash__, added when __eq__ is defined. I think > we're better off with the rule being: > > If unsafe_hash=True, raise an exception if __hash__ exists and is not > None. Otherwise add __hash__. > > That's how it used to be with hash=True (in 3.70b1). > > Or is that what you meant by "but if a __hash__ method is present, an > exception is raised"? Notice the word "method", instead of attribute. > > ---------- > > _______________________________________ > Python tracker <report@bugs.python.org> > <https://bugs.python.org/issue32929> > _______________________________________ >

Here's the simplest way I can describe this, and it's also the table used inside the code. The column "has-explicit-hash?" is trying to answer the question "is there a __hash__ function defined in this class?". It is set to False if either __hash__ is missing, or if __hash__ is None and there's an __eq__ function. I'm assuming that the __hash__ is implicit in the latter case. # Decide if/how we're going to create a hash function. Key is # (unsafe_hash, eq, frozen, does-hash-exist). Value is the action to # take. # Actions: # '': Do nothing. # 'none': Set __hash__ to None. # 'add': Always add a generated __hash__function. # 'exception': Raise an exception. # # +-------------------------------------- unsafe_hash? # | +------------------------------- eq? # | | +------------------------ frozen? # | | | +---------------- has-explicit-hash? # | | | | # | | | | +------- action # | | | | | # v v v v v _hash_action = {(False, False, False, False): (''), (False, False, False, True ): (''), (False, False, True, False): (''), (False, False, True, True ): (''), (False, True, False, False): ('none'), (False, True, False, True ): (''), (False, True, True, False): ('add'), (False, True, True, True ): (''), (True, False, False, False): ('add'), (True, False, False, True ): ('exception'), (True, False, True, False): ('add'), (True, False, True, True ): ('exception'), (True, True, False, False): ('add'), (True, True, False, True ): ('exception'), (True, True, True, False): ('add'), (True, True, True, True ): ('exception'), } PR will be ready as soon as I clean a few things up.

I don't know if I'm unique, but I find such a table with 4 Boolean keys hard to understand. I'd rather see it written up as a series of nested 'if' statements.

if unsafe_hash: # If there's already a __hash__, raise TypeError, otherwise add __hash__. if has_explicit_hash: hash_action = 'exception' else: hash_action = 'add' else: # unsafe_hash is False (the default). if has_explicit_hash: # There's already a __hash__, don't overwrite it. hash_action = '' else: if eq and frozen: # It's frozen and we added __eq__, generate __hash__. hash_action = 'add' elif eq and not frozen: # It's not frozen but has __eq__, make it unhashable. # This is the default if no params to @dataclass. hash_action = 'none' else: # There's no __eq__, use the base class __hash__. hash_action = ''

I've been focused on getting the code fix in for the next beta release on 2018-02-26, and leaving the possible parameter name change for later. I don't feel strongly about the parameter name. Right now it's unsafe_hash, per Guido's original proposal.

@steven.daprano the name was +1'ed by many people in the python-dev discussion as sending the right message. So I'm reluctant to change it. If you can cause a landslide of support for `_hash` there we can change it in b3.

 New changeset dbf9cff48a4ad0fd58e1c623ce1f36c3dd3d5f38 by Eric V. Smith in branch 'master': bpo-32929: Dataclasses: Change the tri-state hash parameter to the boolean unsafe_hash. (#5891) https://github.com/python/cpython/commit/dbf9cff48a4ad0fd58e1c623ce1f36c3dd3d5f38 

I'm going to close this. Steven: if you gain support for a parameter name change, please open another issue.

 New changeset 4cffe2f66b581fa7538f6de884d54a5c7364d8e0 by Eric V. Smith (Miss Islington (bot)) in branch '3.7': bpo-32929: Dataclasses: Change the tri-state hash parameter to the boolean unsafe_hash. (GH-5891) (GH-5902) https://github.com/python/cpython/commit/4cffe2f66b581fa7538f6de884d54a5c7364d8e0