When we are talking about "async WSGI" it's not clear for me what
concrete async implementation we are discussing.
In Python world there are at least 3 major async approaches (twisted,
tornado, asyncio) and many minor libraries.

Let's assume we are talking about asyncio way -- it's standardized by
PEP, Guido promotes it and tornado supports asyncio-based code as

In this case "async WSGI" cannot be implemented in Python 2 ---
asyncio itself is Python 3.3+ only.
trollius is not "asyncio compatible library for python 2" -- it's a
port with slightly different API. Supporting both asyncio and trollius
in a non-trivial third-party library makes a mess.
That's why we decided don't make python2 compatible aiohttp implementation.

Having both synchronous and asyncio API in the same WSGI standard is
also impractical.
There are several tries to make WSGI-based frameworks asynchronous.
The only real successful approach is combination of gunicorn,
gevent/eventlet and total sockets monkeypatching. I don't want to
encourage the way -- but  it don't need WSGI protocol changing.
Monkeypatching just doing own dirty work.

As aiohttp author I can see several approaches to make adapters for
running flask, pyramid, django in asyncio way. The most of them uses
aiohttp as a tool for bringing asynchronous into well-known
synchronous framework.

I can state it just doesn't work well. The result is too fragile: yes,
it is asynchronous but has many subtle limitations which may break a
program easy.
It's impossible to write web framework which is synchronous and
asynchronous at the same time.
asyncio poisons any code that it touches, everything tends to became
asynchronous too.

aiohttp is a quite successful asyncio library, it doesn't need WSGI
standard at all and works with raw sockets.
The same is true for tornado and twisted.

I very doubt aiohttp can get benefits from new WSGI.
Please keep it simple and small.
Async web developers need totally different standard not compatible
with old good WSGI (if they need a standard at all at current stage).
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to