Raymond Hettinger <[email protected]> added the comment:
> What killer use case am I missing?
There's no killer use case. I just thought it weird that hte builtin hash()
function ever returned a negative number.
> This is a change of documented behaviour that will affect
> 3rd party libraries that provide numeric types, like NumPy
> and gmpy; it should not be done lightly.
Okay, I'm happy to drop this. It was only a minor nuisance.
Am not sure at what point we ever guaranteed that hash() would return negative
numbers, or any particular number. That was probably a mistake. I thought the
guarantees were all higher level metamorphic invariants such as hash(x) ==
hash(y) when x == y and {type(x), type(y)} ⊂ {bool, int, float, Decimal,
Fraction, complex}.
BTW, I'm not sure why the numeric hashes are not getting all 64 bits in to play:
from random import randrange, expovariate
from secrets import token_hex, token_bytes
for random_hash in [
lambda : hash(randrange(2**100)) % 2**64,
lambda : abs(hash(expovariate(1.0))) % 2**64,
lambda : hash(token_hex()) % 2**64,
lambda : hash(token_bytes()) % 2**64,
]:
print(max(random_hash().bit_length() for i in range(10_000)))
Outputs:
61
61
64
64
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue37807>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
