[Python-Dev] Py3k and asyncore/asynchat

[Thomas Wouters]

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

> On Mon, Mar 24, 2008 at 3:04 PM, Thomas Wouters <thomas at python.org> wrote:
> >
> > On Fri, Feb 15, 2008 at 9:11 PM, Josiah Carlson <
> josiah.carlson at 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.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080324/12929d8d/attachment.htm