PEP 234: Iterators

[Peter Caven]

I really like the idea of returning different kinds of iterators for
dictionaries as described:

>           for key, value in dict.iteritems(): ...
>
>           for value in dict.itervalues(): ...
>
>           for key in dict.iterkeys(): ...
>

But in case nobody has suggested it yet, perhaps the default case:

for x in dict

should iterate over items, and that:

key,value in dict

would then maintain the desirable symmetry.

This would open up some further interesting possibilities such as specifying
either the key or the value
as an object implementing the __eq__ operation in various ways (regular
expressions, etc...).
... but I'm sure you've all already thought of that: :-)

-- Peter Caven

---------------------


"Guido van Rossum" <guido at digicool.com> wrote in message
news:mailman.988683902.13127.python-list at python.org...
> Here's a revised version of the Iterator PEP (started by Ping).  I
> plan to make this a standard language feature in Python 2.2.
>

--snipped--

>     - There is still discussion about whether
>
>           for x in dict: ...
>
>       should assign x the successive keys, values, or items of the
>       dictionary.  The symmetry between "if x in y" and "for x in y"
>       suggests that it should iterate over keys.  This symmetry has been
>       observed by many independently and has even been used to "explain"
>       one using the other.  This is because for sequences, "if x in y"
>       iterates over y comparing the iterated values to x.  If we adopt
>       both of the above proposals, this will also hold for
>       dictionaries.
>
>       The argument against making "for x in dict" iterate over the keys
>       comes mostly from a practicality point of view: scans of the
>       standard library show that there are about as many uses of "for x
>       in dict.items()" as there are of "for x in dict.keys()", with the
>       items() version having a small majority.  Presumably many of the
>       loops using keys() use the corresponding value anyway, by writing
>       dict[x], so (the argument goes) by making both the key and value
>       available, we could support the largest number of cases.  While
>       this is true, I (Guido) find the correspondence between "for x in
>       dict" and "if x in dict" too compelling to break, and there's not
>       much overhead in having to write dict[x] to explicitly get the
>       value.  We could also add methods to dictionaries that return
>       different kinds of iterators, e.g.
>
>           for key, value in dict.iteritems(): ...
>
>           for value in dict.itervalues(): ...
>
>           for key in dict.iterkeys(): ...
>


--snipped--