hashability

[Carl Banks]

On Aug 12, 10:37 am, James Stroud <jstr... at mbi.ucla.edu> wrote:
> Steven D'Aprano wrote:
> > Well there you go -- why on earth would you prohibit None as a dictionary
> > key??? That's a serious failure.
>
> roentgen 1% python
> Python 2.5 (r25:51908, Sep 20 2006, 17:36:21)
> [GCC 3.4.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> py> hash(None)
> 135543872
>
> mbi136-176 98% /usr/bin/python
> Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> py> hash(None)
> 2030240
>
> That's why. Read the whole thread. You are one of the abrasive ones.

FYI: If you need the actual hash value to be consistent across
versions of Python the built hash function won't suffice.  The
language doesn't guanrantee they will persist across versions.  (IIRC,
there was a change to the hash value of longs at one point related to
int/long unification issues.)

Now, when I saw your explanation I assumed that your persistence
mechanism merely doesn't preserve identity (unlike, say, simple
pickling, which does), meaning that objects that were once identical
might be reconstituted as non-identical (or vice versa), which would
be an issue if these objects are stored in dicts or sets.  Equality
must be preserved for dict keys and set members to continue to work
property.  However, the actual hash code doesn't need to be preserved.

As was mentioned already, None is guaranteed by the language to be
equal to itself, so equality is preserved and there should be no issue
with it, even if the hash code changes across invocations.

Now, if you are doing something weird with the hash value itself--
which I highly discourage--then all bets are off.


Carl Banks