[issue43475] Worst-case behaviour of hash collision with float NaN

[Christoph Groth]

Christoph Groth <christoph at grothesque.org> added the comment:

Hello.  I would like to point out a possible problem that this change to CPython has introduced.

This change looks innocent, but it breaks the unwritten rule that the hash value of a number (or actually any built-in immutable type!) in Python depends only on its value.

Thus, before this change, it was possible to convert a tuple of floats into a numpy array and back into a tuple, and the hash values of both tuples would be equal.  This is no longer the case.

Or, more generally, any hashable tuple could be pickled and unpickled, without changing its hash value.  I could well imagine that this breaks real code in subtle ways.

Likewise, it is now no longer possible to provide a library of sequences of numbers that always hashes like built-in tuples.  (As "tinyarray", of which I am the author, did.)

----------
nosy: +cwg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________