[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
> script".

  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

  Anything else?


More information about the Twisted-Python mailing list