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> -- http://mail.python.org/mailman/listinfo/python-list
