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
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