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

[Fredrik Lundh]

Mike Meyer wrote:

> Backwards compatability. The guarantee on the order of keys() and
> values() predates items() (and iteritems()).

according to the SVN repository, the type originally had "keys" and
"has_key" only.  "values" and "items" were both added in the same
checkin (may 1993).

performance is of course another aspect; if you *need* two parallel
lists, creating a list full of tuples just to pull them apart and throw
them all away isn't exactly the most efficient way to do things.

(if performance didn't matter at all, we could get rid most dictionary
methods; "iterkeys", "in", and locking should be enough, right?)

> Maybe dropping the guarantee should be considered for P3K, on the off
> chance that either keys or values could be made faster at some point
> in the future. But I don't see it as a big deal.

the guarantee only means that the type must use the same algorithm
to traverse the dictionary data structure for both "keys" and "values".
I'm not aware of any dictionary algorithm that doesn't maintain a link
between keys and values, so that's not really much of a restriction...

</F>