PEP 255: Simple Generators

[Carsten Geckeler]

On Mon, 18 Jun 2001, Tim Peters wrote:

> [Russell E. Owen]
> > This sounds like an interesting and really useful proposal. However,a
> > few details are worrisome to me:
>
> You should catch up with the discussion on the Python-Iterators list (as
> mentioned in the PEP announcement), where these have already been discussed
> several times.  I'll only give brief summaries here.
>
> > * A generator looks like a function until you find the "yield" statement
> > inside. I think this will make the code much harder to read. One keyword
> > buried anywhere in a function totally changes its behavior. If a
> > generator acted like a function until it hit "yield", this wouldn't be
> > so bad, but it sounds as if generators have enough significant
> > differences (such as restrictions on and a changed meaning for return)
> > that they are very different beasts.
> >
> > I'd much rather see a declaration up front that this is going to be a
> > generator. E.g. add a new keyword such as "generator".
>
> Who would this help?  Seriously.  There's nothing special about a generator
> to a caller, except that it returns an object that implements the iterator
> interface.  While the latter is important to know, there are many ways to
> construct iterators in 2.2 without using generators at all.  This is better
> communicated via documentation (e.g., make the first line of the docstring
> "Generate ..." instead of "Return ...").

>From my POV a generator is something special, even -- how you pointed out
-- it's not for the caller.  But a single "yield" *is* changing the way
the function/generator is executed, and this way is really very special
compared to normal functions.

> On the other end, someone modifying the generator isn't going to miss that
> it *is* a generator:  all the control flow will focus on feeding
> intermediate results to yield statements.  IOW, you worry too much <wink>.

But when I'm browsing through a source it may help me very much if I could
see at the `def' line if it's a regular function or a generator.

> > * The unusual use of "return" and the associated restriction of no
> > expression list. What "return" means in a generator is "raise StopIter",
> > not return. I personally really dislike using a keyword for multiple
> > vaguely similar purposes. Look at "static" in C++ for an example of
> > where this can lead.
>
> "return" means "I'm done" in any kind of function, generator or not.  You
> can raise StopIteration instead if you feel you must, but then you're
> focusing on an implementation detail, and that's not helping anyone.

But I have to rely that a single "return" raises a StopIter exception when
I want to catch it.  So why not raise it explicitly as "raise StopIter"
when I have to catch it explicitly as "except StopIter" anyway?

> Guido appears to feel quite strongly about this one, so if you want to
> push it I suggest finding a better analogy than C++'s (over)use of
> static.
>
> I'll note that in Icon, "yield" is spelled "suspend", and "return
> expression" is allowed, meaning "I'm done, but I have one last useful value
> to suspend with".  It's possible Python may grow that meaning too, but it
> was thought better to keep it more restrictive at first.

Bye, Carsten
-- 
Carsten Geckeler