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

[Oren Tirosh]

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.

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.  

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.

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.

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. 

silent errors delenda est

	Oren