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

[Oren Tirosh]

On Mon, Jul 15, 2002 at 01:40:41PM +1200, Greg Ewing wrote:
> Oren Tirosh <oren-py-d@hishome.net>:
> 
> > The hypothetical IteratorExhausted is an error.
> 
> Calling it IteratorExhaustedError would make this clearer.
> 
> But I'm not sure it would be a good idea to complexify
> the iterator protocol any more than absolutely necessary,
> and thus place an extra burden on all iterator implementors.

Let's look at the options:  (are there any I forgot?)

1. Define StopIteration as a sticky state.  People will write code that 
relies on this behavior. The code will sometimes fail when run on 2.2.x or
with certain existing user iterators. It's probably the worst possible 
combination: you have to implement this in your iterators but you can't 
rely on it in code that may run on 2.2 or get iterators from libraries
written before this was made into a requirement.

2. Leave things the way they are.  Since *almost* all builtin iterators 
behave this way people will continue to write code that relies on this.  
It will silently fail for some builtin iterators and user iterators.

3. Silently fix all iterators to be in a StopIteration sink state.  Even
worse than #2. It looks like version 2.2 is going to live a long time.
This will cause subtle and hard-to-find differences in behavior between 2.2
and 2.3.

4. Require iterators to raise an exception.  Places an extra burden on all
iterator implementors.  A lot of existing code will suddenly be redefined
as not kosher.

5. Leave it officially undefined but raise an exception for all or even some
builtin iterators. Raising an exception for even one popular type (listiter) 
would be more than enough to discourage code that relies on this behavior.
No extra burden is placed on iterator implementers. No change to iterator
protocol definition. No existing code is suddenly non-conforming. A small
amount of code may break but at least it will raise a meaningful exception.

  silent-errors-delenda-est-ly yours,

	Oren