[Web-SIG] PEP 444 != WSGI 2.0

[P.J. Eby]

At 12:38 PM 1/2/2011 -0800, Alice Bevan­McGregor wrote:
>On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>>>I'd suggest we just embrace it, adding minor tweaks as necessary, 
>>>until we reach some sort of technical impasse it doesn't address.
>
>Async is one area that 3333 does not cover, and that by not having a 
>standard which incorporates async means competing, incompatible 
>solutions have been created.

Actually, it's the other way 'round.  I wrote off async for PEP 333 
because the competing, incompatible solutions that already existed 
lacked sufficient ground to build a spec on.

In effect, any direction I took would effectively have either blessed 
one async paradigm as the correct one, or else been a mess that 
nobody would've used anyway.

And this condition largely still exists today: about the only common 
ground between at least *some* async Python frameworks today is the 
use of greenlets...  but if you have greenlets, then you don't need a 
fancy async API in the first place, because you can just "block" 
during I/O from the POV of the app.

The existence of a futures API in the stdlib doesn't alter this much, 
either, because the async frameworks by and large already had their 
own API paradigms for doing such things (e.g. Twisted deferreds and 
thread/process pools, or generator/greenlet-based APIs in other frameworks).

The real bottleneck isn't even that, so much as that if you're going 
to write an async WSGI application, WSGI itself can't define enough 
of an async API to let you do anything useful.  For example, you may 
still need database access that's compatible with the async 
environment you're using...  so you'd only be able to write portable 
async applications if they didn't do ANY I/O outside of HTTP itself!

That being the case, I don't see how a meaningfully cross-platform 
async WSGI can ever really exist, and be attractive both to 
application developers (who want to run on many platforms) and 
framework developers (who want many developers to choose their platform).


>On 2011-01-02 12:00:39 -0800, Guido van Rossum said:
>>Actually that does sound like an opinion on the technical merits. I 
>>can't tell though, because I'm not familiar enough with PEP 444 to 
>>know what the critical differences are compared to PEP 3333. Could 
>>someone summarize?
>
>Async, distinction between byte strings (type returned by 
>socket.read), native strings, and unicode strings,

What distinction do you mean?  I see a difference in *how* you're 
distinguishing byte, native, and unicode strings, but not *that* 
they're distinguished from one another.  (i.e., PEP 3333 
distinguishes them too.)


>thorough unicode decoding (moving some of the work from middleware 
>to the server),

What do you mean by "thorough decoding" and "moving from middleware 
to server"?  Are these references to the redundant environ variables, 
to the use of decoded headers (rather than bytes-in-unicode ones), or 
something else?


>The async part is an idea in my head that I really do need to write 
>down, clarified with help from agronholm on IRC.  The futures PEP is 
>available as a pypi installable module, is core in 3.2, and seems to 
>provide a simple enough abstract (duck-typed) interface that it 
>should be usable as a basis for async in PEP 444.

I suggest reviewing the Web-SIG history of previous async 
discussions; there's a lot more to having a meaningful API spec than 
having a plausible approach.  It's not that there haven't been past 
proposals, they just couldn't get as far as making it possible to 
write a non-trivial async application that would actually be portable 
among Python-supporting asynchronous web servers.

(Now, if you're proposing that web servers run otherwise-synchronous 
applications using futures, that's a different story, and I'd be 
curious to see what you've come up with.  But that's not the same 
thing as an actually-asynchronous WSGI.)