[Guido van Rossum] > > What about this example? > > >>> l = [] > > >>> li = iter(l) > > >>> li.next() > > Traceback (most recent call last): > > File "<stdin>", line 1, in ? > > StopIteration > > >>> l.extend([1, 2, 3]) > > >>> li.next() > > 1 > > > > does the list iterator violate the proposed behavior? > Alternatively, we could change the PEP to make this officially > undefined (or at least up to the iterator used). If you change the PEP so the behaviour is undefined in the protocol, then, you will have to separately document the behaviour for all iterators which are produced by the various means available in standard Python, and people will have to remember these differences. Would it be perceived as shocking (or not?) in the example above, having to produce another iterator "li = iter(l)" before reusing it? If not, then I presume regularity and consistency of behaviour should prevail. Are there other problematic cases from the Python distribution itself? Maybe the iteration protocol should invite implementors at returning forever, if it has returned it once by a particular instance of an iterator, only for the sake of consistency with all iterators provided by Python itself, but without making this a hard requirement. So if for some strange application, users want to do differently, they could validly do nevertheless. -- François Pinard http://www.iro.umontreal.ca/~pinard
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