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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4