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.