Oren, I like the direction this is going in, but I have some reservations about any protocol which requires users to avoid using a simple method name like next() on their own multi-pass sequence types unless they intend their sequence to be treated as single-pass. One other possibility: if x.__iter__() is x, it's a single-pass sequence. I realize this involves actually invoking the __iter__ method and conjuring up a new iterator, but that's generally a lightweight operation... -Dave From: "Oren Tirosh" <oren-py-d@hishome.net> > There is no need for a new type of iterator. It's ok that iterators are > disposable. If I need multiple iterations I don't want to copy the > iterator - I prefer to ask the original iterable object for a new iterator. > All I need is some way to know whether the iterable object (container) can > produce multiple iterators that generate the same sequence. > > An object is re-iterable if its iterators do not modify its state. > > The iterator of an iterator is itself. Calling the next method, by > definition, modifies the internal state of an object. Therefore anything > that has a next method is not re-iterable. > > "hasattr(obj,'__iter__') and hasattr(obj, 'next')" is a good signature of > a non re-iterable object. Unfortunately, the opposite is not true. One > iterable object in Python produces iterators that modify its state when > their .next() method is called - the file object. > > I have just submitted a patch that makes a file into an iterator (i.e. adds > a .next method to files). With this change all Python objects that have > an __iter__ method and no next method produce iterators that do not modify > the container. Another possibility would be to make file iterators that > use seek or re-open the file to avoid modifying the file position of the > parent file object. I don't think that would be a good idea because files > can be devices, pipes or sockets which are not seekable. > > I think it may be a good idea to add a note to the documentation pages > about the iterator protocol that the iterators of a container should not > modify the state of the container. If you think they must it's probably > a good sign that your 'container' is not really a container and maybe it > should be an iterator rather than produce iterators of itself. > > Oren > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev
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