[Python-Dev] Termination of two-arg iter()
Guido van Rossum
guido@python.org
Tue, 16 Jul 2002 08:07:54 -0400
> 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/)