[Python-3000] Need help completing ABC pep

[Guido van Rossum]

On 4/20/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> It's not listed as an open issue, but when looking at the list of ABCs,
> I noticed a potential solution to a different problem we have
> occasionally wrestled with: the unfortunate side-effects of having a
> default __hash__ method defined on object.
>
> If the details of collections.Hashable.__hash__ are declared to be
> implementation dependent rather than having it always return 0, then we
> can get rid of object.__hash__.
>
> For CPython, collections.Hashable.__hash__ would then just invoke id()
> on the object, and other implementations can also do whatever they
> currently do for object.__hash__

I don't like that at all. I want to force folks to implement a
__hash__ that matches their __eq__. As soon as you implement an __eq__
you need to redefine __hash__. I'd much rather have the default
__hash__ be correct but insanely slow than fast but incorrect -- it
being incorrect is much harder to debug, and it smells of premature
optimization. As Hashable.__hash__ is abstract, you are *forced* to
define your own hash.

I do see your point though: object.__hash__ makes it possible to use
all sorts of objects as dict keys by default, as long as they don't
implement __eq__. But perhaps this is not such a good idea and we
should just get rid of it and add __hash__ back to specific objects
that are useful to use as keys? (E.g. classes but not iterators, to
take some extreme examples.)

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