[Python-Dev] Re: Termination of two-arg iter()

[Tim Peters]

[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