On Tue, Sep 21, 2010 at 1:39 AM, Andrew Bennetts andrew@bemusement.org wrote:
Guido van Rossum wrote: [...]
Unless you want to propose to include Twisted into the stdlib, this is not going to be ready for inclusion into Python 3.2.
I don't think anyone has suggested "include Twisted". What is being suggested is "include twisted.internet.defer, or something about as useful."
Let's consider just how hard it would be to just adding twisted/internet/defer.py to the stdlib (possibly as 'deferred.py'). It's already almost a standalone module, especially if pared back to just the Deferred class and maybe one or two of the most useful helpers (e.g. gatherResults, to take a list of Deferreds and turn them into a single Deferred that fires when they have all fired).
The two most problematic dependencies would be:
1) twisted.python.log, which for these purposes could be replaced with a call to a user-replaceable hook whenever an unhandled error occurs (similiar to sys.excepthook). 2) twisted.python.failure... this one is harder. As glyph said, it provides "an object that represent[s] an exception as raised at a particular point, associated with a particular stack". But also, as he said, it's a mess and could use a clean up. Cleaning it up or thinking of a simpler replacement is not insurmountable, but probably too ambitious for Python 3.2's schedule.
My point is that adding the Deferred abstraction to the stdlib is a *much* smaller and more reasonable proposition than "include Twisted."
-Andrew.
No on was seriously proposing including twisted wholesale. There has been discussion, off and on *for years* about doing including a stripped down deferred object; and yet no one has stepped up to *do it*, so it might be hilariously easy, it might be a 40 line module, but it doesn't matter if no one steps up to do the pep, and commit the code, and commit to maintaining it.
jesse