[Python-Dev] Termination of two-arg iter()

[Ka-Ping Yee]

On Sun, 14 Jul 2002, Guido van Rossum wrote:
> The question is, should we place the burden on iterator users to avoid
> calling next() after the first StopIteration, or should we place the
> burden on iterator implementations?  Since by far the most common
> iterator use case is still a single for loop, which already does the
> right thing, it's not at all clear to me which is worse.

As a general design philosophy question, my vote would be for
placing the burden on the implementations.  If code reuse is all
it's cracked up to be, you're going to use the iterator more times
than you implemented it.  Moreover, the more consistent the
implementation is, the more widely it can be used.  (Tim just said this.)

As for the specifics of the iterator protocol, there seem to be
two separate issues here:

1.  After StopIteration, should iterators be allowed to keep going?

2.  Should an empty iterator be distinguishable from an exhausted iterator?


For 1, i don't think i've seen anyone come down too strongly on
the "yes" side.  There have been a couple of examples as to why
this might be cute, but i don't think they are compelling.  My
opinion is that, if you are trying to make an iterator keep going
after it has stopped, it's just a way of abusing the iterator to
represent a sequence of sequences.

You can always get the behaviour you want by explicitly describing
both kinds of sequence.  Tim's example of getting paragraphs out
of a file demonstrates exactly why we don't want to encourage the
abuse of one iterator to represent a sequence of sequences: you're
going to be in trouble if you can't distinguish between the
termination conditions for the two kinds of sequences.


For 2, i believe Andrew and Oren want the answer to be "yes",
but Guido and Aahz want the answer to be "no".  I think the answer
should be "yes".  An exhausted iterator is not the same thing as
a freshly-created iterator on an empty sequence, and allowing one
to silently pass for the other is going to lead to problems.

I'm not going to insist that IndexError should be the effect, as
Guido's preference to keep IndexError for randomly-indexable
sequences seems reasonable; anything distinguishable from
StopIteration is fine.


-- ?!ng