[Twisted-Python] Twisted in Python STDLIB?
exarkun at divmod.com
exarkun at divmod.com
Mon Oct 11 19:55:39 EDT 2004
On Mon, 11 Oct 2004 15:51:11 -0400, Glyph Lefkowitz <glyph at divmod.com> wrote:
>On Mon, 2004-10-11 at 15:31, exarkun at divmod.com wrote:
> > So, uh, yea. I'd love to see a mature, stable Twisted (or more
> > likely Twisted subset) in the standard library. I think a few parts
> > of Twisted are even almost ready for this to be considered, but aside
> > from some of the things in twisted/python/, much of it still requires
> > work.
> I had almost finished composing an identical email when this one
> arrived. So, I'll play devil's advocate:
> I think that part of the question Ed is asking is, "when can we have
> some of Twisted in the stdlib rather than asyncore". Considering how
> ancient and creaky asyncore is looking right now, I think it might be
> valid to consider some small subset of Twisted that subsumes asyncore's
> functionality for inclusion in the standard library.
> Of course this should be post-split. I don't think it makes much sense
> to try to do something like this now.
> Were this to happen, I would suggest it be in a different module name,
> "twistedcore" or something, to allow a stable interface to remain in the
> standard library, which would have a hope of being easily
> plug-compatible with future Twisted versions, but would not hamstring
> the ability of the Twisted team to put out new versions.
Obviously the package should be named "internet" :)
> This might also assuage Guido's concerns about framework-structured
> code; we could elide utilities such as twistd, and instead provide
> convenience functions for users to write their own daemonization, et.
> al. This would at least provide a minimal platform for running
> Twisted-compatible event handlers, to even out the curve between
> "install Twisted as a dependency" and "just run this stand-alone
So what would actually need to be fixed for this to happen?
1) Readable abstract reactor implementation
2) Producer/Consumer API repair
3) Non-recursive Deferred implementation (or "internet" could be Deferred-less, but that would seem to suck)
4) Less terrifying Failure implementation (or, again, Failure-less in the stdlib)
5) Better test coverage (for example, more than one unit test for
6) Latexified documentation (probably automatable)
7) Something with Interfaces
More information about the Twisted-Python