[Fran=E7ois Pinard] > 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 stan= dard > Python, and people will have to remember these differences. Not necessarily. The standard dodge is to say "undefined" and just l= eave it at that. This is a way of saying that the language so strongly disco= urages the practice that it refuses to saying anything about what happens if= you do it, but that it's not going to stop you if you're determined to do it= . If you do it anyway, it's at your own risk (as if anything you do is eve= r done at someone else's risk <wink>). > Would it be perceived as shocking (or not?) in the example above, h= aving > to produce another iterator "li =3D iter(l)" before reusing it? Jeff's example was too simple to make "the problem" here clear. If y= ou get a new iterator, you'll start over from the beginning of the list. As= is, you continue where the last next() call left off: >>> x =3D range(2) >>> n =3D iter(x).next >>> n() 0 >>> n() 1 >>> n() Traceback (most recent call last): File "<stdin>", line 1, in ? StopIteration >>> x.extend([6, 7]) >>> n() 6 >>> n() 7 >>> n() Traceback (most recent call last): File "<stdin>", line 1, in ? StopIteration >>> *Some* code out there may be relying on that, despite that the behavi= or violates what the tail end of the PEP says. thank-god-the-protocol-doesn't-have-three-methods<wink>-ly y'rs - ti= m
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