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 tim.peters
Recipients christian.heimes, hongqn, pitrou, rhettinger, tim.peters, vstinner
Date 2013-10-12.04:51:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1381553494.15.0.309049495898.issue19224@psf.upfronthosting.co.za>
In-reply-to
Content
-0.

Since hash(None) is currently based on None's memory address, I appreciate that it's not reliable (e.g., use different releases of the same compiler to build Python, and hash(None) may be different between them).

The docs guarantee little about hash() results, so applications relying on cross-machine - or even same-machine cross-run - consistency are broken.

It's trivial code bloat to special-case None, but it leaves a world of other hash() behaviors as-is (essentially "undefined").  The `portable_hash()` function in the DPark source is a start at what needs to be done if an application wants reliable hashes.  But it's just a start (e.g., it's apparently relying on cross-platform consistency for `hash(integer)` and `hash(string)`, etc).

Since CPython will never promise to make _all_ of those consistent across platforms and releases, I'd rather not even start down that road.   Making the promise for `hash(None)` would be an attractive nuisance.
History
Date User Action Args
2013-10-12 04:51:34tim.peterssetrecipients: + tim.peters, rhettinger, pitrou, vstinner, christian.heimes, hongqn
2013-10-12 04:51:34tim.peterssetmessageid: <1381553494.15.0.309049495898.issue19224@psf.upfronthosting.co.za>
2013-10-12 04:51:34tim.peterslinkissue19224 messages
2013-10-12 04:51:33tim.peterscreate