This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients alex, docs@python, loewis, pitrou, terry.reedy
Date 2012-01-04.04:07:20
SpamBayes Score 1.48255e-05
Marked as misclassified No
Message-id <1325650042.15.0.203440691379.issue13707@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-01-04 04:07:22terry.reedysetrecipients: + terry.reedy, loewis, pitrou, alex, docs@python
2012-01-04 04:07:22terry.reedysetmessageid: <1325650042.15.0.203440691379.issue13707@psf.upfronthosting.co.za>
2012-01-04 04:07:21terry.reedylinkissue13707 messages
2012-01-04 04:07:20terry.reedycreate