[Python-Dev] Re: Single- vs. Multi-pass iterability

[Ka-Ping Yee]

On Wed, 17 Jul 2002, Guido van Rossum wrote:
[...]
> OK, that's clear.
[...]
> Yes.
[...]
> Correct.

Neat!  So much understanding.

> Now, weren't you a co-author of the Iterator PEP?  I wish you'd
> brought this up then.  Or maybe you did, and I overruled you.  Sorry
> then.

Indeed, i wrote the first draft of the PEP, though it was very
different from what we have today; it's been largely rewritten.
The big design changes happened at the iterator BOF, so unfortunately
there's no e-mail record of the debate.

I recall that __iter__ made me uncomfortable, but i don't recall to
what extent i expressed this.  I don't remember whether there was any
overruling.  But it doesn't really matter; it's today now, and here
we are.  It is true that i failed to understand or express the issue
well enough to have an effect on the design.  I will cheerfully accept
blame if it somehow means we'll end up with a nicer language. :)

> But I don't think we can withdraw this so easily.  It's not the end of
> the world.

I would be pleased to see a migration path (perhaps along the lines
of Dave's suggestion, with warnings for a while), but i won't throw
myself off a bridge if it doesn't happen.

I do think there is some potential for errors caused by misunderstandings
about whether or not "for x in y" is destructive.  That's the thing that
worries me the most.  I think this is the main reason why the old
practice of abusing __getitem__ was bad, and thus helped to motivate
iterators in the first place.  It seems serious enough that migrating to
something that distinguishes destructive-for from non-destructive-for
could indeed be worth the cost.

The destructive-for issue may seem superficially unrelated to the
__next__-naming issue.  As i see it, the __next__-naming issue is
related to the mandatory-__iter__ issue (because some people view
__iter__ as a type flag), which is related to the destructive-for issue.


-- ?!ng