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

[P.J. Eby]

I made a few errors in that massive post...

At 12:00 PM 1/8/2011 -0500, P.J. Eby wrote:
>My major concern about the approach is still that it requires a fair 
>amount of overhead on the part of both app developers and middleware 
>developers, even if that overhead mostly consists of importing and 
>decorating.  (More below.)

The above turned out to be happily wrong by the end of the post, 
since no decorators or imports are actually required for app and 
middleware developers.


>You can then implement response-processing middleware like this:
>
>     def latinize_body(body_iter):
>         while True:
>             chunk = yield body_iter
>             if chunk is None:
>                 break
>             else:
>                 yield piglatin(yield body_iter)

The last line above is incorrect; it should've been "yield 
piglatin(chunk)", i.e.:

     def latinize_body(body_iter):
         while True:
             chunk = yield body_iter
             if chunk is None:
                 break
             else:
                 yield piglatin(chunk)

It's still rather unintuitive, though.  There are also plenty of 
topics left to discuss, both of the substantial and bikeshedding varieties.

One big open question still in my mind is, are these middleware 
idioms any easier to get right than the WSGI 1 ones?  For things that 
don't process response bodies, the answer seems to be yes: you just 
stick in a "yield" and you're done.

For things that DO process response bodies, however, you have to have 
ugly loops like the one above.

I suppose it could be argued that, as unintuitive as that 
body-processing loop is, it's still orders of magnitude more 
intuitive than a piece of WSGI 1 middleware that has to handle both 
application yields and write()s!

I suppose my hesitance is due to the fact that it's not as simple as:

     return (piglatin(chunk) for chunk in body_iter)

Which is really the level of simplicity that I was looking 
for.  (IOW, all response-processing middleware pays in this 
slightly-added complexity to support the subset of apps and 
response-processing middleware that need to wait for events during 
body output.)