[Python-Dev] Synchronous and Asynchronous servers in the standard library

Bob Ippolito bob at redivi.com
Sun Nov 7 20:19:09 CET 2004

On Nov 7, 2004, at 13:39, Josiah Carlson wrote:

> I suppose the question comes down to; should there be a meta framework
> for developing servers in Python that specifies a separation between 
> the
> protocol logic and how data gets to that protocol logic?  The desire is
> for a mechanism to allow people to create a single version of a server
> in their favorite framework (SocketServer, asyncore, Twisted, or 
> other),
> and for others to be able to use them in their favorite framework with
> little difficulty.

That's not really practical.  You can't use synchronous protocol code 
in an asynchronous server without threads or Stackless... so what's the 
point?  As for asynchronous frameworks that are compatible with the 
Python license, I'm only aware of asyncore (which people generally feel 
should be deprecated) and Twisted.

I think the best course of action would be to create some stripped down 
derivative of Twisted.  A couple changes off the top of my head would 
make it more suitable for the standard library:

-  Allow generators to be easily used for asynchrony (much easier to 
write synchronous-like code in that style, this has been demonstrated 
by several people)
-  Throw a blocking API on top because some people will want to use it 
in a blocking manner (Twisted's testing framework already has this 
-  Allow more than one reactor per process (necessary to support the 
previous, because invariably people will use the blocking API from 
several threads)
-  Bring in some of the standard protocols (SMTP, HTTP, ...)  but not 
the higher-level versions when available (twisted.web) because those 
are so much more volatile.


More information about the Python-Dev mailing list