[Python-Dev] Single- vs. Multi-pass iterability
Andrew Koenig
ark@research.att.com
11 Jul 2002 11:31:47 -0400
David> I keep running into the problem that there is no reliable way
David> to introspect about whether a type supports multi-pass
David> iterability (in the sense that an input stream might support
David> only a single pass, but a list supports multiple passes). I
David> suppose you could check for __getitem__, but that wouldn't
David> cover linked lists, for example.
Here's a suggestion for a long-term strategy for solving this
problem, should it be deemed desirable to do so:
Right now, every iterator, and every object that supports
iteration, must have an __iter__() method. Suppose we augment
that with the following:
A new kind of iterator, called a multiple iterator, that
supports multiple iterations over the same sequence.
A requirement that every object that supports multiple
iteration have a __multiter__() method that yields a
multiple iterator over its sequence, in addition to
an __iter__() method that yields a (multiple or single)
iterator (so that every sequence that supports multiple
iteration also supports single iteration).
A requirement that every multiple iterator support the
following methods:
__multiter__() yields the iterator object itself
__iter__() also yields the iterator object itself
(so that every multiple iterator is
also an iterator)
__next__() return the next item from the container
or raise StopIteration
__copy__() return a distinct, newly created multiple
iterator that iterates over the same
sequence as the original, starting from
the current element.
Note that when the last multiple iterator has left an element, there
is no possibility of going back to that element again unless the
sequence itself provides a way of doing so. Therefore, for example,
it might be possible for files to provide multiple iterators without
undue space inefficiency.
--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark