On Sat, Jul 13, 2002 at 07:07:36PM -0400, Guido van Rossum wrote: > Actually, not. Under "Resolved Issues" the PEP has this: > > - Once a particular iterator object has raised StopIteration, will > it also raise StopIteration on all subsequent next() calls? > Some say that it would be useful to require this, others say > that it is useful to leave this open to individual iterators. > Note that this may require an additional state bit for some > iterator implementations (e.g. function-wrapping iterators). > > Resolution: once StopIteration is raised, calling it.next() > continues to raise StopIteration. > > So I misremembered, and Tim didn't read the PEP closely enough. :-) > > > I'm happy to leave this be: the docs match the implemenation, I'm > > sure *someone* relies on that by now, and the behavior is easy to > > explain as-is. > > Hm. Given what the PEP says, I'm ready to have this fixed (even in > 2.2.2). I can't call code relying on this sane. What about this example? >>> l = [] >>> li = iter(l) >>> li.next() Traceback (most recent call last): File "<stdin>", line 1, in ? StopIteration >>> l.extend([1, 2, 3]) >>> li.next() 1 does the list iterator violate the proposed behavior? Jeff
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