On Mon, Mar 24, 2008 at 10:21 PM, Adam Olsen <rhamph@gmail.com> wrote:

On Mon, Mar 24, 2008 at 3:04 PM, Thomas Wouters <thomas@python.org> wrote:
>
> On Fri, Feb 15, 2008 at 9:11 PM, Josiah Carlson <josiah.carlson@gmail.com>
> wrote:
> > Twisted core has been proposed, but I believe the consensus was that
> > it wasn't desirable, generally.
> >
>
> I remember only a couple of dissenting voices, and only a small number of
> participants. Of the dissenting voices, I do not recall any actual arguments
> about undesireability, just misunderstandings of how Twisted actually works.
> Getting Twisted core (meaning Deferreds, a simple reactor and the Protocol
> class) into the core is still on my TODO list.
>
>
> > I'm also pretty sure that people learn twisted because everyone learns
> > twisted. It's one of those buzz-words ;).
> >
>
> I think that's quite an unfair assessment, even in jest :) Twisted is well
> worth learning to actually use it, as it's a very versatile event loop and
> does it best to integrate nicely with other event systems. And including it
> in the standard library improves integration with other event loops by
> creating a single interface. It's not a matter of dropping it in, though; it
> requires some careful structuring to avoid embarrassing situations like we
> have with the xml package, but still people to provide their own reactor.
>
> In case you're wondering how the twisted reactor in the stdlib is useful to
> people not using Twisted, take a look at what you currently need to do to
> combine stdlib modules like urllib and ftplib with event systems like
> Tkinter and PyGTK. Not to mention that the Twisted implementations of
> various protocols are really quite, quite good -- in many cases quite a lot
> better than the stdlib ones. But including those takes yet more time.

In that sense it'd be competing with safethread for inclusion in
Python. Whereas safethread requires little if any API changes,
twisted requires an entirely new API that can be event-driven. Worse,
we'd likely to be stuck maintaining both APIs for a long time, if not
forever.

I am not going to worry about this for the time being. Even if safethread goes in and becomes ubiquitous, Twisted is still a very valid approach to the problem. And I'm not just saying that because I don't subscribe to your enthusiasm of safethreads as a concept or as an implementation :)

Twisted may be one of the best (if not *the* best) ways of writing
concurrent programs today, but it doesn't need to be in the stdlib for
that. If safethread is going to solve many of the same problems, with
less changes required by the users of the language, then this is the
wrong time to add twisted.

You must have missed the part where we already have a large set of event loops, and not having a single interface to them is in fact hurting people. Twisted goes out of its way to interact nicely with event loops, but it can only do that with ones it knows about (and are versatile enough to hook into.) Having a single event system in the standard library is definitely advantageous, even if safethreads were available everywhere and the performance in the common case was satisfactory. It used to be the case that people thought asyncore was this standard event system, but it's long since ceased to be.