[Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

[P.J. Eby]

At 05:39 AM 1/8/2011 -0800, Alice Bevan­McGregor wrote:
>As a quick note, this proposal would signifigantly benefit from the 
>simplified syntax offered by PEP 380 (Syntax for Delegating to a 
>Subgenerator) [1] and possibly PEP 3152 (Cofunctions) [2].  The 
>former simplifies delegation and exception passing, and the latter 
>simplifies the async side of this.
>
>Unfortunately, AFIK, both are affected by PEP 3003 (Python Language 
>Moratorium) [3], which kinda sucks.

Luckily, neither PEP is necessary, since we do not need to support 
arbitrary protocols for the "subgenerators" being called.  This makes 
it possible to simply "yield" instead of "yield from", and the 
trampoline functions take care of distinguishing a terminal 
("return") result from an intermediate one.

The Coroutine class I suggested, however, *does* accept explicit 
returns via "raise StopIteration(value)", so it is actually fully 
equivalent to supporting "yield from", as long as it's used with an 
appropriate trampoline function.

(In fact, the structure of the Coroutine class I proposed was stolen 
from an earlier Python-Dev post I did in an attempt to show why PEP 
380 was unnecessary for doing coroutines.  ;-) )

In effect, the only thing that PEP 380 would add here is the syntax 
sugar for 'raise StopIteration(value)', but you can do that with:

     def return_(value):
         raise StopIteration(value)

In any case, my suggestion doesn't need this for either apps or 
response bodies, since the type of data yielded suffices to indicate 
whether the value is a "return" or not.  You only need a subgenerator 
to raise StopIteration if you want to return something to your caller 
that *isn't* a response or body chunk.