Re: [Python-Dev] getting rid of default object.__hash__ (SF 660098)
At 01:04 PM 12/22/03 -0800, Guido van Rossum wrote:
New-style classes inherit a default __hash__ from object, but this is incorrect if the inheriting object defines __eq__ or __cmp__.
This has been reported several times; the roll-up SF entry is 660098, which has the proposed patch attached as newpatch.txt.
I've long pondered this, and it seems the best solution is to simply not define __hash__ on the base object class. After all, you don't inherit __eq__ or __cmp__ either; the default comparison behavior is supplied by intrinsic behavior of comparisons, and the default hash() behavior is also supplied by intrinsic behavior of hash().
Does anybody have any reason why I shouldn't check in this change in 2.4? There's no unit test that fails if I do this.
Would this mean that instances of the following class: class Dummy(object): pass would no longer be usable as dictionary keys? I guess the parts I'm not clear on are 1) whether dictionaries call the equivalent of 'hash(key)' or 'key.__hash__()', and 2) whether 'hash(Dummy())' will do something meaningful.
Would this mean that instances of the following class:
class Dummy(object): pass
would no longer be usable as dictionary keys? I guess the parts I'm not clear on are 1) whether dictionaries call the equivalent of 'hash(key)' or 'key.__hash__()', and 2) whether 'hash(Dummy())' will do something meaningful.
That class would still be usable. hash(Dummy()) sees that there's no __eq__ or __cmp__ override and then uses the default hash. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum
-
Phillip J. Eby