On 4/20/07, Nick Coghlan <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
