[Python-Dev] Re: Single- vs. Multi-pass iterability

Guido van Rossum guido@python.org
Thu, 18 Jul 2002 16:08:54 -0400


> I didn't add the whole thing verbatim, because the tone doesn't fit:
> it was written with the intent of motivating a change to the
> protocol, rather than describing what the protocol is.  Presumably
> we don't want the PEP to say "__iter__ is a red herring".
> 
> There's a bunch of issues flying around here, which i'll try to
> explain better in a separate posting.  But i wanted to take care
> of Guido's request first.  I have toned down and abridged my text
> somewhat, and strengthened the requirement for __iter__().  Here
> is what the "API specification" section now says:
> 
>     Classes can define how they are iterated over by defining an
>     __iter__() method; this should take no additional arguments and
>     return a valid iterator object.  A class that wants to be an
>     iterator should implement two methods: a next() method that behaves
>     as described above, and an __iter__() method that returns self.
> 
>     The two methods correspond to two distinct protocols:
> 
>     1. An object can be iterated over with "for" if it implements
>        __iter__() or __getitem__().
> 
>     2. An object can function as an iterator if it implements next().
> 
>     Container-like objects usually support protocol 1.  Iterators are
>     currently required to support both protocols.  The semantics of
>     iteration come only from protocol 2; protocol 1 is present to make
>     iterators behave like sequences.  But the analogy is weak -- unlike
>     ordinary sequences, iterators are "sequences" that are destroyed
>     by the act of looking at their elements.

Find up to here.

>     Consequently, whenever any Python programmer says "for x in y",
>     he or she must be sure of whether this is going to destroy y.

I don't understand why this is here.  *Why* is it important to know
whether this is going to destroy y?

--Guido van Rossum (home page: http://www.python.org/~guido/)