hashing mutable instances

[Bernhard Herzog]

Michael Hudson <mwh at python.net> writes:

> Bernhard Herzog <bh at intevation.de> writes:
>
>> IMO it depends on what equality means for instances. E.g. if two
>> instances are only equal if they're identical, i.e. a == b is equivalent
>> to a is b, then defining __hash__ can be very useful, because then you
>> can use them in dictionaries and mutability doesn't really matter
>> because no change to one instance can make it equal to a nother
>> instance.
>
> Um.  In that case why define __hash__ or __eq__ at all?

Good question. I didn't know that that was the default implementation of
__hash__. It's not documented AFAICT, but it does seem to be the case. I
wonder why, even though it's useful.

The language reference for __hash__ says:

   If a class does not define a __cmp__() method it should not define a
   __hash__() operation either;

Seems a bit outdated in that it only mentions __cmp__ here and not
__eq__ as well as it does right after the semicolon, but that would not
indicate to me that hash works for an instance without a hash method. Of
course the sentence above could be taken to mean that if you define
neither method the defaults to the right thing, but that would seem very
obscure to me.

Anyway, I've found that if you end up comparing objects very often is
can be a substantial performance gain if you do define __eq__ even
though it ends up doing the same as the default comparison. At least for
old style classes when __eq__ is not defined python tries __cmp__ and
__coerce__ and __getattr__ if defined is called for all of them.

Then, once you have defined __eq__ you also need to have __hash__ if you
want your objects to be hashable.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/