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

[bonono at gmail.com]

Peter Hansen wrote:
> bonono at gmail.com wrote:
> > Which is also my initial puzzle, items() and iteritems() already gives
> > you the tuples, why such gurantee or the others ? Doesn't that violate
> > the general idiom that if we can do certain thing in one way, there
> > better be one and only one way.
> >
> > Are there other usage scenarios that would be benefit from this as the
> > example given is not convincing for me.
>
> As Jeff's reply emphasizes, the "examples" show tuples with *value* and
> then *key*, not the other way around which is what .items() and
> .itemitems() gives you.
>
> Anyway, you didn't ask for good examples of use, just "why is it
> guaranteed", and that's all I was showing you.  Whether it was a good
> idea might be an interesting discussion, but probably not a particularly
> useful one given once again that it's unlikely this particular feature
> could be undone now that code exists (we can assume) which is dependent
> on it.
>
Please don't take it as a challenge, it was not. If it was, it was
about the need for the guarantee, not about you not giving me the
answer I want. But it is really wondering why ?

As for the (k,v) vs (v,k), I still don't think it is a good example. I
can always use index to access the tuple elements and most other
functions expect the first element to be the key. For example :

a=d.items()
do something about a
b = dict(a)

But using the imaginary example :

a = zip(d.values(), d.keys())
do something about a
b = dict(a) # probably not what I want.