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

[Oren Tirosh]

On Sun, Jul 14, 2002 at 10:58:02AM -0400, Barry A. Warsaw wrote:
> 
> >>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
> 
>     GvR> -1.  IndexError belongs to sequences.  I don't like the idea
>     GvR> of raising another exception at all -- we should either keep
>     GvR> things the way they are, or continue to raise StopIteration
>     GvR> forever once it's been raised.  Other suggestions don't make
>     GvR> sense to me.
> 
> I think it would be fine to leave the situation as is
> (i.e. undefined).  You can use the PEP to encourage a particular
> behavior but I'm not sure it needs to be required ("SHOULD" in RFC
> terms, but not "MUST").

I'd like it to stay underfined. The issue is how should the iterators of 
builtin types actually behave within this undefined space.

Iterables are very similar to sequences.  A lot of code could use either
one without any changes.  It's precisely because of this similarity that I
hate it when they do behave differently - and don't even report it. Files 
and pipes are very similar too. A lot of code could work with either one 
but if this code tries to seek on a pipe it will get an exception. Just
imagine what would happen if pipes failed silently if you tried to seek 
back to the beginning of the file.

I have much respect for whatever makes or doesn't make sense to Guido but I 
have been using iterators and generator functions extensively (obsessively?) 
for over 8 months now and the current behavior doesn't make sense to me.

I guess the reason I ran into this has to do with my style of interactive 
use of the Python prompt.  I recall a previous command, change the paramters 
of one of the processing stages in the dataflow and repeat the process.  
Then I wonder why I get an empty result - one of the temporary results I 
stored to a variable wasn't re-iterable. Is it too much to expect an
exception?  "Errors should never pass silently."

	Oren