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.)
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
