[Python-Dev] '*' instead of 'yield'?

Tim Peters tim.one@home.com
Sun, 5 Aug 2001 20:46:44 -0400

[Thomas Wouters]
> ...
> There is no reason for 'yield' not to be an expression. "not" and
> "and" and "lambda" and such are all expressions too, remember. But
> making 'yield' a statement is a very good choice, in my eyes. What
> should
>    ((yield a) ** (yield b) and (yield c)) ^ (yield e) / yield f
> yield ? 'yield' is too similar to 'return' for it not to be a statement.

If we had been able to think of an "obviously correct" way for yield to
return a value, we would have -- but we didn't, so we didn't <wink>.

The temptation is that it's very handy for a coroutine transfer to "act
like" a function call from a transferor's POV:  this gives a way for *its*
resumer to communicate info back to it.  I first saw this in Icon, and it
was a huge and obvious improvement over Simula 67, wherein coroutines could
communicate only via stuffing values in shared globals.  Since PEP 255's
"Simple Generators" are only semi-coroutines, the need isn't acute, but
could still be handy at times.

Anyway, Neil implemented *lots* of ideas that didn't survive:  we all agreed
to slice out features left and right until the Simple in "Simple Generators"
earned its name.  They're still fancier than Icon's and CLU's generators
(because explicitly resumable even in the absence of magical control
context) all the same.

I'm curious to see how people use the "extra" power in practice, and can't
predict which kinds of extensions would be truly useful.  Until real life
makes that clear(er), I'm inclinded to resist any change; in the meantime,
we haven't precluded turning yield into an operator someday, neither
extending its syntax as a statement.

right-now-it's-the-simplest-thing-that-could-possibly-work-ly y'rs  - tim