> 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/)
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