Why is dictionary.keys() a list and not a set?

[bonono at gmail.com]

bonono at gmail.com wrote:
> Mike Meyer wrote:
> > "bonono at gmail.com" <bonono at gmail.com> writes:
> > > Christoph Zwerschke wrote:
> > >> jepler at unpythonic.net schrieb:
> > >> > You can already get a set from a dictionary's keys in an efficient manner:
> > >> >>>>l = dict.fromkeys(range(10))
> > >> >>>>set(l)
> > >> > Set([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
> > >> Good point. I expected that set(l) = set(l.items()) and not
> > >> set(l.keys()), but the latter would not work with mutable values. See
> > >> discussion with Martin.
> > > puzzled. items() return tuples which I believe can be element of set ?
> > > Or I misread you ?
> >
> > Not all tuples can be elements of a set. Elements of a set have to be
> > hashable. Tuples compute their hash by hashing their contents. If
> > their contents aren't hashable, the tuple isn't hashable, and hence
> > can't be an element of a set. If the values in the dictionary aren't
> > hashable, then the tuples returned by items() won't be hashable
> > either, and hence can't be elements of a set.
> >
> A related issue, from the doc :
>
> Set elements are like dictionary keys; they need to define both
> __hash__ and __eq__ methods.
>
> and dir(any_tuple) would show __hash__ and __eq__, would that be a bit
> confusing as even though tuple has these two properties(or whatever
> terms it should be called), it really depends what it contains ?
>
> Or in other words, tuple is hashable if and only if every object it
> contains is also hashable ?
>
> If that is the case, would it be better to correct the doc to say such
> thing ?

And this, again from the doc(about mapping objects):

A mapping object maps immutable values to arbitrary objects.

Seems that is questionable too.

a=(1,[])
d={}
d[a]=1

again would give TypeError, list object are unhashable.