Oren> There is no need for a new type of iterator. It's ok that Oren> iterators are disposable. If I need multiple iterations I don't Oren> want to copy the iterator - I prefer to ask the original Oren> iterable object for a new iterator. All I need is some way to Oren> know whether the iterable object (container) can produce Oren> multiple iterators that generate the same sequence. You are assuming that you still have access to the original iterable object. But what if all you have is an iterator? Then you need to be able to ask the iterator for a new iterator. Oren> An object is re-iterable if its iterators do not modify its state. Oren> The iterator of an iterator is itself. Calling the next method, Oren> by definition, modifies the internal state of an Oren> object. Therefore anything that has a next method is not Oren> re-iterable. That's not the only possible definition of an iterator. I'm thinking, in part, about how one might translate some of the C++ standard-library algorithms into Python. If that translation requires that the user always supply the original container, rather than using iterators only, then some algorithms become harder to express or less ueful.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4