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

Glyph Lefkowitz glyph at divmod.com
Fri Jul 1 14:24:35 EDT 2005


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

>>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.

Well, it's a subject that comes up periodically, and I have some new 
thoughts, so let me play devil's advocate here:

> 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.

This will always be a concern, but Python manages to get releases out 
every so often, and the stdlib *does* change sometimes.  We've been 
pretty good about preserving compatibility for a release or two 
ourselves.  I think it is a reasonable concern but not a reason to stop 
this entirely.

> 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:

IMHO the point here is the trivial functionality.  As far as I can tell 
from the few examples of event-driven applications that I use which I 
didn't write :-), there is a progression that many event-driven Python 
programs go through these days:

	- Implement something with asyncore
	- realize asyncore's deficiencies, start enhancing it
	- discover Twisted, re-implement networking code (from scratch)

If the event loop in Python provided similar interfaces to the one in 
Twisted, the amount of work involved in stage 3 could be greatly reduced.

> 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 - 

So let's not pretend that they're the same thing.  'from eventloop 
import listenTCP' -> 'from twisted.internet import reactor'.  They can 
just share a set of common interfaces.  The big problem with xmlplus was 
that it changed the behavior of a built-in package, so let's not ever do 
that again.   amk's article specifically recommends this solution.

> 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.

Right.  But, her code uses Twisted-like interfaces so she doesn't have 
to re-write it all.  Given that a lot of network applications are 
trivial one-offs, this step will not always happen.

> 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
> (http://peak.telecommunity.com/DevCenter/PythonEggs).

I don't think the issue is "less" or "more" but "better".  The Python 
standard library is of a highly non-uniform quality.  Whether or not 
Twisted gets added, I think asyncore should be removed, or at least 
strongly deprecated.




More information about the Twisted-Python mailing list