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