[Python-Dev] Rationale behind lazy map/filter (original) (raw)
Random832 random832 at fastmail.com
Tue Oct 13 12:49:32 EDT 2015
- Previous message (by thread): [Python-Dev] Rationale behind lazy map/filter
- Next message (by thread): [Python-Dev] Rationale behind lazy map/filter
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): [Python-Dev] Rationale behind lazy map/filter
- Next message (by thread): [Python-Dev] Rationale behind lazy map/filter
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]