> 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
> - 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).
> - There's an operation to create an iterator from a function and a
> sentinel value. This is spelled as iter(function, sentinel). For
> 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.