Home Original page

Recursion limit problems

Terry Reedy tjreedy at udel.edu
Mon May 14 14:20:40 EDT 2007 
"elventear" <elventear at gmail.com> wrote in message 
news:1179156916.706892.144770 at y80g2000hsf.googlegroups.com...
On May 12, 12:25 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Fri, 11 May 2007 19:17:57 -0300, elventear <elvent... at gmail.com>
> escribió:
> "The only required property is that objects which compare equal have the
> same hash value; it is advised to somehow mix together (e.g., using
> exclusive or) the hash values for the components of the object that also
> play a part in comparison of objects. If a class does not define a
> __cmp__() method it should not define a __hash__() operation either; if 
> it

I suspect/believe that the above should be __cmp__() or __eq__() both for 
uniformity with the usage below and also because objects do not need to be 
ordered (__cmp__) to be used as dict keys.

> defines __cmp__() or __eq__() but not __hash__(), its instances will not
> be usable as dictionary keys. If a class defines mutable objects and
> implements a __cmp__() or __eq__() method, it should not implement
> __hash__(), since the dictionary implementation requires that a key's 
> hash
> value is immutable (if the object's hash value changes, it will be in the
> wrong hash bucket)."

Thanks for the information. I have a doubt regarding the wording in
the paragraph on top.

Since I am defining a hash for my object, it makes sense that I should
be able to define equality. But I am not sure about inequality, in my
specific case. The paragraph above mentions that __cmp__ should be
defined if I define a __hash__, but in the default behaviour of
__cmp__ inequality is included. So what should I do? Also why is
equality necessary to be defined? Do dicts only use __hash__ or do
they use equality as well?
===============

Dicts first compare hashes and if they are equal, then check equality.  If 
two unequal strings have the same hash value, as is possible of course 
(given only 2**32 possible hashes and many more possible strings), both can 
still be used as different keys.  Ditto for unequal numbers.  Or for a 
number and string with equal hashes.  And so on.  The first quoted 
sentence, about mixing, is directed at minimizing such hash collisions.

Terry Jan Reedy
More information about the Python-list mailing list