Concurrency support?

John Cowan cowan at
Mon Jun 26 11:58:54 PDT 2006

Graydon Hoare scripsit:

> If this is what PEP 342 is proposing

I think your analysis is right, though I had been hoping there was something
better available.

> then I must admit the lua strategy
> seems much more appealing: make any "yield" expression return control to 
> the nearest dynamic "resume". That would let the low level i/o functions 
> know about yield points, and all the logic inbetween the scheduler and 
> the i/o functions ignore them.


> So, follow-on question: what's *wrong* with the lua strategy? Moreover, 
> why did the python strategy turn out this way? Did the python group just 
> not understand the better strategy? Were they concerned about the 
> restriction of being unable to yield through C stack frames? That seems 
> unlikely since the same restriction probably applies to PEP 324 yields.
> Maybe they were bound by semi-compatibility with the existing (and even 
> weaker) iterator/generator scheme in earlier python versions?

That seems plausible.  In Python without this PEP, the caller need not
know whether a procedure is being invoked as a coroutine or a subroutine,
whereas in Lua any procedure can be invoked either way: natively as
a subroutine, or using the coroutine creation functions as a coroutine.
The Python situation can be trivially emulated in Lua by creating a
facade that is invoked as a subroutine and invokes the real coroutine
as a coroutine.

John Cowan  cowan at
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee

More information about the Es4-discuss mailing list