[Python-Dev] For Python 3k, drop default/implicit hash, and comparison

[Guido van Rossum]

Two more thoughts in this thread.

(1) The "key" idiom is a great pattern but I don't think it would work
well to make it a standard language API.

(2) I'm changing my mind about the default hash().

The original default hash() (which would raise TypeError if __eq__ was
overridden but __hash__ was not) is actually quite useful in some
situations. Basically, simplifying a bit, there are two types of
objects: those that represent *values* and those that do not. For
value-ish objects, overriding __eq__ is common and then __hash__ needs
to be overridden in order to get the proper dict and set behavior. In
a sense, __eq__ defines an "equivalence class" in the mathematical
sense.

But in many applications I've used objects for which object identity
is important.

Let me construct a hypothetical example: suppose we represent a car
and its parts as objects. Let's say each wheel is an object. Each
wheel is unique and we don't have equivalency classes for them.
However, it would be useful to construct sets of wheels (e.g. the set
of wheels currently on my car that have never had a flat tire). Python
sets use hashing just like dicts. The original hash() and __eq__
implementation would work exactly right for this purpose, and it seems
silly to have to add it to every object type that could possibly be
used as a set member (especially since this means that if a third
party library creates objects for you that don't implement __hash__
you'd have a hard time of adding it).

In short, I agree something's broken, but the fix should not be to
remove the default __hash__ and __eq__ altogether. Instead, the
default __hash__ should be made smarter (and perhaps the only way to
do this is to build the smarts into hash() again). I do agree that
__cmp__, __gt__ etc. should be left undefined by default. All of this
is Python 3000 only.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)