Home Original page

[Python-Dev] Dataclasses and correct hashability

Nick Coghlan ncoghlan at gmail.com
Sat Feb 3 01:25:15 EST 2018 
On 3 Feb. 2018 1:09 am, "Eric V. Smith" <eric at trueblade.com> wrote:


The problem with dropping hash=True is: how would you write __hash__
yourself? It seems like a bug magnet if you're adding fields to the class
and forget to update __hash__, especially in the presence of per-field
hash=False and eq=False settings. And you'd need to make sure it matches
the generated __eq__ (if 2 objects are equal, they need to have the same
hash value).


I think anyone that does this needs to think *very* carefully about how
they do it, and offering both "hash=True" and "frozen=True" is an
attractive nuisance that means people will write "hash=True" when what they
wanted was "frozen=True".

In particular, having to work out how write a maintainable "__hash__" will
encourage folks to separate out the hashed fields as a separate frozen
subrecord or base class.

If this proves to be an intolerable burden then the short hand spelling
could be added back in 3.8, but once we ship it we're going to be stuck
with explaining the interactions indefinitely.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180203/df11d81f/attachment.html>
More information about the Python-Dev mailing list