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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4