> The base question: does the iteration protocol define what happens if an > iterator's next() method is called after the iterator has raised > StopIteration? Or is that left up to the discretion of the iterator? The latter. Believe it or not, I thought about this during the design of the protocol, and decided that if someone wanted to create an iterator that could somehow continue after raising StopIteration, that should be their problem. Basically, the effect of calling next() after StopIteration is raised is undefined. > If the answer is that it's the iterator's choice, is 2-argument iter() > making the best choice? The rub here is that 2-arg iter was (IMO) > introduced to help iteration-ignorant callables fit into the iteration > protocol, and *because* they're iteration-ignorant they may do something > foolish if called again after their "sentinel" value is seen. If the caller stops calling next(), nothing's wrong. I don't think the callable-iterator object should grow another state bit. But I'm willing to be convinced by information you withheld. --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