Chris Angelico <rosuav at gmail.com> writes: > A well-behaved iterator is supposed to continue raising StopIteration > forever once it's been exhausted. Yes, and that is *precisely* the behavior that causes the problem under discussion. My question was what code depends on this. > Play with that, and see where RuntimeErrors start coming up. I suspect > they'll be rare, but they will happen. My theory is that most circumstances under which this would cause a RuntimeError are indicative of a bug in the algorithm consuming the iterator (for example, an algorithm that hasn't considered iterators and expects to be passed an iterable it can iterate from the top more than once), rather than the current behavior being relied on to produce the intended end result. This is essentially the same argument as PEP 479 - except there it was at least *easy* to come up with code which would rely on the old behavior to produce the intended end result. About the only example I can think of is that the implementation of itertools.zip_longest would have to change.
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