Home Original page

[Python-Dev] Rationale behind lazy map/filter

Steven D'Aprano steve at pearwood.info
Tue Oct 13 19:29:35 EDT 2015 
On Tue, Oct 13, 2015 at 11:26:09AM -0400, Random832 wrote:
> "R. David Murray" <rdmurray at bitdance.com> writes:
> 
> > On Tue, 13 Oct 2015 14:59:56 +0300, Stefan Mihaila
> > <stefanmihaila91 at gmail.com> wrote:
> >> Maybe it's just python2 habits, but I assume I'm not the only one
> >> carelessly thinking that "iterating over an input a second time will 
> >> result in the same thing as the first time (or raise an error)".
> >
> > This is the way iterators have always worked.
> 
> 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.

Anything which looks like this:


for item in iterator:
    if condition: 
        break
    do_this()
...
for item in iterator:
    do_that()


If the condition is never true, the iterator is completely processed by 
the first loop, and the second loop is a no-op by design.

I don't know how common it is, but I've written code like that.

Had we been designing the iterator protocol from scratch, perhaps we 
might have had two exceptions:

class EmptyIterator(Exception): ...
class StopIteration(EmptyIterator): ...

and have StopIteration only raised the first time you call next() on an 
empty iterator. But would it have been better? I don't know. I suspect 
not. I think that although it might avoid a certain class of errors, it 
would add complexity to other situations which are currently simple.


-- 
Steve
More information about the Python-Dev mailing list