[Python-Dev] PEP 340 -- loose ends

[Guido van Rossum]

[Delaney, Timothy]
> PEP 340 does not address "normal" iterators very well, but a
> properly-constructed iterator will behave correctly.

This is by design.

> The PEP though is very generator-focussed.

Disagree. The PEP describes most everything (e.g. the block statement
semantics) in terms of iterators, and then describes how the new APIs
behave for generators.

> The issues I see for "normal"
> iterators (and that need to be addressed/stated in the PEP) are:
> 
>     1. No automatic handling of parameters passed to __next__ and __exit__.
>        In a generator, these will raise at the yield-statement or -expression.
>        A "normal" iterator will have to take care of this manually.

Not sure what you mean by this. If __next__() is defined, it is passed
the parameter; if only next() is defined, a parameter (except None) is
an error. That seems exactly right. Also, if __exit__() isn't defined,
the exception is raised, which is a very sensible default behavior
(and also what will happen to a generator that doesn't catch the
exception).

> This could be an argument to only allow generator-iterators to be used
> with PEP 340 semantics (i.e. continue <EXPR>, block), but I don't think
> it's a very compelling one.

Neither do I. :-)

> Although perhaps the initial implementation could be restricted to
> generator-iterators. So if a for-loop used `continue <EXPR>` it would
> have a check (at the start of the for loop) that the iterator is a
> generator-iterator. Likewise, a block-statement would always include
> this check.

But what would this buy you except an arbitrary restriction?

> As another option, it might be worthwhile creating a base iterator type
> with "correct" semantics.

Well, what would the "correct" semantics be? What would passing a
parameter to a list iterator's __next__() method mean?

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