Generators versus Coroutines

[Timothy Fitz]

Tim Peters <tim.peters at gmail.com> wrote in message 
>
> > Coroutines, in contrast, are like split functions where
> > side effects are often as important or more important than return
> > values. I am currently writing a real time strategy game where I have
> > visual effects and use generators as coroutines which yield after
> > processing a single frame of the effect. I can easily make an object
> > rotate indefinitely with a scant four or five lines of code, all of
> > which is in one place. So knowing that the difference between a
> > generator and a coroutine is minor, I come (in a very roundabout way)
> > to my issue. Why can I use "return" without an expression and it
> > implicitly returns None
> 
> If you explicitly intend to return None as a value, it's terrible
> practice to spell that as
> 
>     return
> 
> instead of as
> 
>     return None
> 
> It's equally terrible practice to rely on that "falling off the end"
> of a Python function returns None, when you expliclty intend to return
> a None value.

It was not that I want to explicitly return None, I specifically don't
want to return anything, it's just that None happens to be the default
for return so it seems like a convention to adhere to.

> If you want a concept of yielding without delivering a value, that's
> simply not a use case Python's generators intended to address.  If you
> wish, you can adhere to a *convention* that "yield None" (or "yield
> False", or "yield 42", ...) means "I'm not really delivering a value".

It's not a use case, but why not? And should it be? I know generators
are semi-coroutines, but the fact is that their useage outside of
value generation is just as useful and should be adressed as such. I
do not see how accepting a plain yield would break anything at all.

I have read the PEP, twice, and I don't see why it -wasn't- addressed.
Seems to me to be a fairly large arbitrary decision.