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.