[Python-Dev] Rationale behind lazy map/filter (original) (raw)

Random832 random832 at fastmail.com
Tue Oct 13 12:08:12 EDT 2015

"R. David Murray" <rdmurray at bitdance.com> writes:

On Tue, 13 Oct 2015 11:26:09 -0400, Random832 <random832 at fastmail.com> wrote:

It does raise the question though of what working code it would actually break to have "exhausted" iterators raise an error if you try to iterate them again rather than silently yield no items. They do raise an error: StopIteration. It's just that the iteration machinery uses that to stop iteration :).

I meant a real error and you know it, both of you. StopIteration is an exception in the technical sense that it can be raised and caught, but it's not an error because it is used for normal control flow. In the plain english meaning of the word, it isn't even an exception.

And the answer to the question is: lots of code. I've written some: code that iterates an iterator, breaks that loop on a condition, then resumes iterating, breaking that loop on a different condition, and so on, until the iterator is exhausted. If the iterator restarted at the top once it was exhausted, that code would break

I'm not suggesting restarting at the top (I've elsewhere suggested that many such methods would be better as an iterable that can be restarted at the top by calling iter() multiple times, but that's not the same thing). I'm suggesting raising an exception other than StopIteration, so that this situation can be detected. If you are writing code that tries to resume iterating after the iterator has been exhausted, I have to ask: why?

I suppose the answer is the same reason people would deliberately raise StopIteration in the ways that PEP479 breaks - because it works and is easy. But that wasn't a reason not to deprecate that.

More information about the Python-Dev mailing list