PEP 255: Simple Generators

[John Machin]

"Russell E. Owen" <owen at astrono.junkwashington.emu> wrote in message news:<9glhg7$dlk$1 at nntp6.u.washington.edu>...
> 
> * 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".

Russell likes Tim's PEP but is worried about some details.
Recursively ...

What exactly are we proposing here:
   def generator <funcname>(<args>):
or
   generator <funcname>(<args>):
or
   something else?
> 
> * 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.
> 
> Several proposals come to mind. They are all compatible with each other:
> 
> 1) Have users explicitly say "raise StopIter" when they mean it.

Yes, please.

> 2) Add a keyword, such as "stop". It could always raise StopIter, or 
> raise a new exception Stop in a non-generator and StopIter in a 
> generator. On the plus side, stop might be handy in other contexts. On 
> the minus side, I doubt it's worth the fuss.

Oh, goody, goody, goody. Tears of joy. Muted shrieks of "I remember
when ...". "Other contexts" could include things like:
   stop 10HEND OF RUN

Hope [some of] this helps,
John