[Python-3000] Spooky behavior of dict.items() and friends

[Mike Meyer]

On Wed, 02 Apr 2008 04:37:05 +0200
"Martin v. Löwis" <martin at v.loewis.de> wrote:

> > So unless I am misinterpreting this, it sounds like the burden of
> > proof now falls on the option to keep the status quo. The thing is
> > that it seems to me that if that an outside observer were to look at
> > this situation, then they might ask why the names are being changed
> > when the current behavior is functional and no one is clamoring for
> > the change.
> 
> I think it's fairly obvious why the 2.x .keys() has to change. It's
> just too wasteful to actually build the list of all keys of a dictionary
> (or even of all values, as you have to create all the tuples as well),
> if all you want to do is to iterate over it, and the most common
> operation of .keys() is to iterate over it in a for look (right?).

I'd say not clear, for two reasons. One is that I pretty much never
use keys() in a for loop, I just use the dictionary.

> Applications that take a snapshot of the .keys() are rare (right?).

And the second is that I don't think it's rare to want to process the
keys in sorted order. It's  not exactly common, but

keys = mydict.keys()
keys.sort()
for key in keys:

In fact, the 2.5 standard library turns up 3 occurrences of
"keys.sort". Given that that's just the ones that used the obvious
name for the list to be sorted

Nowdays, I tend to write

keys = sorted(mydict.keys())	 # Yeah, I know, .keys() is redundant...
for key in keys:

or maybe

for key in sorted(mydict):

both of which are probably slower than the original version unless
sorted switches to an insertion sort if passed a generator.


> The most direct name should be used in the most common scenario,
> which is the for loop. I.e. people who don't think about this
> issue at all should likely do the right thing. For 2.x, this is
> not the case.

I'd say the most direct name is to use the dictionary as an iterator
directly. So if you don't think about it the way I don't think about
it, you get the right thing in 2.x and 3.0.

Given that you the dictionary itself is an iterator, what are the use
cases for wanting the result of the keys() method returning an
iterator where you can't use the dictionary itself? I thought
assignment might be one, but a second reference to the dictionary will
behave the same way in all cases you'd use the dict_keys (hmm -
dict_keys.__xor__???)

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.