[issue13707] Clarify hash() constancy period

Terry J. Reedy report at bugs.python.org
Wed Jan 4 05:07:22 CET 2012


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given that the doc says that use of hash() is to compare dict keys, it does not seem wrong to me to suggest that hash() should be usable to do so.

I believe id() and consequently hash() are unique among builtins in being run-dependent. That is currently documented for id() but not for hash(). Given that people seriously asked whether we can randomize hash() with each run, because 'people' 'expect' it to remain rather constant, it does not seem useless to clarify that it can change with each run. I am sure my wording could be improved. An alternative would be 'Hash values for built-in objects are constant for each run but not necessarily thereafter."

If you take into account what people can do with special methods, some of the other entries seem more wrong that my suggestion. For instance:
"len(s) Return the length (the number of items) of an object." and
"str(obj ... When only object is given, this returns its nicely printable representation." These are true only for built-in objects, but the policy is to leave out the qualification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13707>
_______________________________________


More information about the Python-bugs-list mailing list