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
--
http://mail.python.org/mailman/listinfo/python-list
