Iterators: Would "rewind" be a good idea?

[Edward Elliott]

Heiko Wundram wrote:

> But, think of the following: what if the iterator computes the values at
> runtime, and you're not iterating over a "predefined" list of some sort?
> Do you want the machinery to store the state of the iterator at every
> earlier point in time (sometimes this may not even be possible, think of
> socket communication handled by iterators, or of some state being kept in
> a C extension outside of the grasp of the Python interpreter), and to
> restore the iterator to this point? 

This is why the C++ STL has independent forward and backward iterator types.
Iterating over containers in memory generally supports both.  Iterating
over stdin or a socket would only support forward iteration.  I can't
recall any examples of backwards-only iteration atm... maybe popping values
off a stack.  My STL's a bit rusty.

Anyway, python iterators could provide a prev() method to go with next(). 
If the iterator doesn't support backwards iteration (sockets, generators),
it could raise an exception.  Then you could implement rewind as:

def rewind (iter)
    try:
        while iter.prev():
            pass
    except StopIteration:
        pass

There's no faster way in general to rewind an iterator (think linked lists),
just like there's no fast_forward() to automatically jump current iterators
to the end of the sequence (which may not terminate anyway, a la
itertools.count).

Note that backwards iterators are different from iterating in reverse. 
Namely, the former let's you move back and forth at will in a sequence,
while the latter is just a one-way street from back to front.

My knowledge of Python's iterators is kind of sketchy, so I may have missed
something.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net