[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
functionality)
- 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.
-bob
More information about the Python-Dev
mailing list