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

[Guido van Rossum]

> On Mon, Jul 15, 2002 at 11:15:58AM -0400, Guido van Rossum wrote:
> > I'm still only considering two options:
> > 
> >   (a) leave the status quo, or
> >   (b) implement (and document!) the "sink-state" rule from the PEP.
> 
> (c) leave it officially undefined but make all builtin iterator behave
> consistently.

What would be the point of that?  Since we can't enforce the
sink-state rule for 3rd party iterators, this is no different from (b)
except that 3rd party implementers have less of an incentive to fix
their implementations.

> Implementing consistent post-StopIteration behavior for builtin
> iterators is not too hard and doesn't require adding flags and
> special cases - when the iterator is exhausted it can clean up and
> decref any referenced objects and change its type to a
> StoppedIterator type.  I can write a patch.

Don't bother.  I already wrote a patch, SF patch 580331.

Changing the type is evil (you can't change the type unless the memory
deallocation policies are the same), so I won't do that.

> I would prefer this StoppedIterator type to raise a new exception
> when its next() is called.  I assume you would want it to be a
> StopIteration sink.

You got that right, buddy.

> As the risk of sounding like a broken record I will repeat my
> position: I consider the StopIteration sink state to be a silent
> error. It makes an exhausted iterator behave just like an iterator
> of an empty sequence.  Because iterators and iterables can be mixed
> freely it results in silent failures when a function that requires a
> re-iterable object gets an iterator.  Iterables can serve as a
> replacement for sequences in most cases.  When they are not I'd like
> to get an error, please.

This is inconsistent with your position (c) above, which gives you no
guarantees in this case.

I also think you're mistaken in your desire.  Iterables do *not* serve
as sequence replacements.

> When I pass a popened pipe to a function that expects a real file I
> will get an error if the function tries to perform a seek. I
> wouldn't want the seek operation to fail silently but that's
> more-or-less the equivalent of what iterators currently do.

It would be an error to try to use __getitem__ on an iterator.

Please give up this line of request -- I'm tired of this argument.

--Guido van Rossum (home page: http://www.python.org/~guido/)