[Twisted-Python] Event queue in the Python std lib

Itamar Shtull-Trauring itamar at itamarst.org
Fri Jul 1 10:53:21 EDT 2005

On Fri, 2005-07-01 at 10:56 +0100, Matt Goodall wrote:

> Obviously, having the event loop part in the std lib has a number of 
> benefits but it should also put pressure on all event driven toolkits to 
> conform to the common API. Everything would then work together and the 
> world would be a happier, shinier place ;-).

Which event driven toolkits are you talking about, besides Twisted?

> GvR suggested that someone should start a PEP to talk around, which 
> seems like a sensible thing to do, although I don't know if anyone with 
> enough knowledge of the reactor and working with other event loops has 
> time right now.

On the whole I don't think now, if ever, is the time to add Twisted or a
Twisted-based event loop to the Python standard library. There are a
number of issues:

1. Release cycles: Python releases on its own schedule, which may not
match up to the needs of bug fixes or feature additions to Twisted.

One solution is a separate Twisted package you can install, overriding
the stdlib's. Since Twisted, even split up, is quite large, this would
probably be necessary for most non-trivial functionality anyway, which
leads to:

2. Installing separate package issues. As PyXML has shown, having a
separate package which overrides or extends a built-in stdlib API works
terribly.  http://www.amk.ca/conceit/xmlplus.html covers some of the
issues, but there's also - 

3. Limited usefulness of minimal APIs: lets say we add Twisted to the
stdlib. Because it's large, we don't want to add *everything*. We can't
add SSL probably cause that depends on pyOpenSSL which is LGPLed,
probably don't want the pygtk reactor because that occasionally needs
updates for new pygtk releases, etc.. So Jane User decides to build a
network application, plays a bit with the TCP client code, and now says
"OK great, now to add a GUI and TLS support" - and suddenly she needs to
install the full Twisted framework to do that.

I would argue that Python needs less in the stdlib, not more; specific
external software packages will probably grow into de-facto standard
packages, but there's no reason for them to be in stdlib. PyXML is
usually installed separately because people need the extended features
the full package has, and the same would happen to Twisted. The only
real benefit to inclusion in the stdlib is ease of distribution, and a
better way to deal with that is to put more work into things like Eggs

Itamar Shtull-Trauring <itamar at itamarst.org>

More information about the Twisted-Python mailing list