[Web-SIG] PEP 444 and asynchronous support, continued

Alex Grönholm alex.gronholm at nextday.fi
Mon Jan 17 04:49:06 CET 2011


After a weekend of experimentation with several asynchronous frameworks 
including gevent, tornado and twisted (and writing one myself too), and 
these are my findings so far:

- asynchronous socket implementations vary wildly across different 
frameworks
- gevent is the fastest, tornado comes second while twisted is pretty slow
- twisted provides the most comprehensive support for implementing 
protocols, while the other two mostly just provide low level support for 
asynchronous sockets
- futures seem to have a significant overhead (from the thread 
synchronization)
- gevent provides the easiest programming interface with greenlets, 
since it pretty much lets you write asynchronous code as you would write 
it synchronously
- gevent could make use of the regular, synchronous PEP 444 API by 
monkey patching the socket library (through its import monkey; 
monkey.patch_socket() call)

The significance of this for the Python web standards effort is that 
providing an asynchronous API that works for the existing asynchronous 
frameworks does not seem feasible. I'd love to see a solution for this 
in the standard library, but gevent's monkey patching approach, while 
convenient for the developer, cannot obviously work there. Before an 
asynchronous WSGI API can be provided, this lower level problem needs to 
be solved first. The crucial question is: is it possible to provide 
gevent's level of convenience through the standard library, and if not, 
what is the next best solution? I'd like to hear everyone's thoughts on 
this (especially Guido's).


More information about the Web-SIG mailing list