recognizing empty iterators

[Raymond Hettinger]

[Michele Simionato]
> BTW, the fact that an empty iterator is True is somewhat strange,
> considering that [],() and "" are False; on the other hand, generic
> objects are True, so the point can be debated ...

Requiring iterators to know whether they are empty *before* being
called would be like from requiring them to know their length in
advance (after all, the falsity of [] and () stems from their __len__()
methods returning zero).  Non-sequential access and the absence
of a __len__() method are what give iterators their character.  IOW,
iterators are *supposed* to not be the same as sequences.

Viva la difference.


[Timothy Delaney]
> It is impossible to know, in the general case, if an iterator is empty.
> The primary reason for this is that many iterators are destructive
> e.g. file iterators. A wrapper iterator can be used around a
> destructive iterator that caches information, but that's about the
> best you can do unless the iterator is resettable.

> An iterator may in fact be conceptually empty at one instant, then
> the next instant not be empty...

> All it is possible to know is if an iterator has been exhausted
> *for now* - and that is if it raises StopIteration. Technically this
> does not mean that the iterator is permanently exhausted - it could
> start returning values at a later date, but this would be very
> confusing to people ;)

Yes, it was.  So, Guido decreed that once a iterator has returned
StopIteration, it will continue to do so on subsequent calls to
it.next().  Promptly, all of Python's iterators were modified to
comply.  IOW, iterators can and do stay "permanently exhausted".

However, Tim is essentially correct in focusing on the "just-in-time"
nature of iterators.  Part of the core concept for iterators is to *not*
know what lies ahead.



Raymond Hettinger