Why is dictionary.keys() a list and not a set?
"Martin v. Löwis"
martin at v.loewis.de
Sat Nov 26 23:03:24 CET 2005
Christoph Zwerschke wrote:
>> This is not true. The second definition of __hash__ does not meet
>> the specifications:
>> "The only required property is that objects which compare equal have the
>> same hash value"
> As Mike has written in his last posting, you could easily "fix" that by
> tweaking the equality relation as well. So technically speaking, Mike is
> probably right.
No. If you define both __hash__ and __eq__ consistently, then __hash__
would meet the specification. As posted in the example, __hash__ does
not meet the specification, contrary to Mike's claim that it does.
> It would completely break common-sense semantics,
> because for mylist2, if I have a= and b= then I will have a!=b.
> This would not be very reasonable, but probably allowed by Python.
If you have a= and b=, then *always* a==b; you cannot
change the semantics of list displays. To achieve !=, you
would need to have a=mylist2(), b=mylist(). Whether or not
it is common sense that classes named "mylist2" compare equal
if they consist of the same items, I don't know - I personally don't
have any intuition as to what a class named "mylist2" should or
should not do.
Just that it has "list" in its name provides not sufficient clue: for
example, IdentityDictionary has "dictionary" in its name, yet I would
*not* expect that equality is used to compare keys, but instead I
would expect that identity is used.
More information about the Python-list