[Python-Dev] Shall I start adding iterators to Python 2.2?

Tim Peters tim.one@home.com
Fri, 20 Apr 2001 03:15:30 -0400


[Guido]
> I've got a fairly complete implementation of iterators along the lines
> of Ping's PEP (slightly updated).
> ...
> My question is: should I just merge this code onto the trunk (making
> it part of 2.2), or should we review the design more before committing
> to this implementation?

My answer is both!  *Most* of what you described is no longer controversial;
2.2 is mondo pre-alpha (so we're not "stuck" with anything you check in now);
and it's much more convenient (for me - heh) to try out if it's in the
regular build tree.  I bet Greg Wilson would like it for his Set PEP work
too, as abusing the __getitem__ protocol for set iteration is giving him
headaches.  WRT what may still be controversial points, there's no substitute
for trying a thing.

> ...
> - The test "key in dict" is implemented as "dict.has_key(key)".  (This
>   was done by implementing the sq_contains slot.

That's probably controversial, but also easy to rip out (sounds approximately
self-contained) if the peasants storm your castle with flaming dungballs
<wink>.

> - iter(dict) returns an iterator that iterates over the keys of dict
>   without creating a list of keys first.  This means that "for key in
>   dict" has the same effect as "for key in dict.keys()" as long as
>   the loop body doesn't modify the dictionary (assignment to existing
>   keys is okay).

Ditto.

> - There's an operation to create an iterator from a function and a
>   sentinel value.  This is spelled as iter(function, sentinel).  For
>   example,
>
>     for line in iter(sys.stdin.readline, ""):
>       ...
>
>   is an efficient loop over the lines of stdin.
>
> - But even cooler is this, which is totally equivalent:
>
>     for line in sys.stdin:
>       ...

Here you're going to be hoisted on your own petard (Jeremy can explain that
one <wink>):  if

    for x in dict:

has to iterate over keys because

    if x in dict:

tests for keys, then shouldn't

    if line in sys.stdin:

also check sys.stdin for the presence of line?  Not according to me, but it's
a not wholly unreasonable question.

> - Not yet implemented, but part of the plan, is to use iterators for
>   all other implicit loops, like map/reduce/filter, min/max, and the
>   "in" test for sequences that don't define sq_contains.

Check it into the trunk and people can help out with that stuff.

+0.9.