[Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

[Thomas Wouters]

On 2/14/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> glyph at divmod.com wrote:
> > On 08:52 pm, theller at ctypes.org wrote:
> >
> >  >When I last looked at twisted (that is several years ago), there were
> >  >several reactors - win32reactor, wxreactor, maybe even more.
> >
> > Only the very top-most level decides which reactor the application will
> use.
>
> This is a worry, because it implies that there has to
> *be* a top level that knows what kind of reactor the
> whole application will use, and all parts of the
> application need to know that they will be getting
> their reactor from that top level.
>
> That may not be the case. For example, you want to
> incorporate some piece of event-driven code written
> by someone else into your gtk application. But it
> wasn't written with gtk in mind, so it doesn't know
> to use a gtkreactor, or how to get a reactor that it
> can use from your application.
>
> This is not my idea of what another poster called a
> "one-stop shop" -- a common API that different pieces
> of code can call independently without having to know
> about each other.
>
> To my mind, there shouldn't be a "reactor" object
> exposed to the application at all. There should just
> be functions for setting up callbacks. The choice of
> implementation should be made somewhere deep inside
> the library, based on what platform is being used.


Eh, your own example seems to argue the opposite. If the choice for reactor
was made somewhere deep inside the library, how does it know to use the GTK
reactor? Only the code using GTK knows that it's going to need the GTK
reactor. The generic code just uses whatever reactor was selected,
automatically.

The reason the decision should be made at the topmost level is that this is
the most visible and adaptive location. A library or framework has to handle
a boundless number of variations of environment, use and co-operation with
other libraries and frameworks, whereas the topmost script knows exactly
what it wants to do. A library that uses PyGTK can say 'I need the GTK
reactor', but it would be wrong. All it needs is a reactor that interacts
nicely with GTK. If there are multiple reactors that integrate nicely with
GTK, there is no reason for the library to insist on one particular
implementation. And it could be in the way, if a second library needs a
different kind of integration and it knows of a reactor that supports both
that *and* GTK integration. And if the whole system breaks, for some reason,
the first place the programmer will look is in his own code, not deep inside
another library.

For what it's worth, I think a single event-handling mainloop API in the
standard library is a *great* idea. Using part of Twisted for it (suitably
adapted) is an even greater idea: a whole lot of work and brainpower went
into Twisted's core, and it wasn't wasted. Duplicating the effort would be a
big mistake and a terrible waste. A from-scratch implementation of an
event-handling mechanism will not solve any of the "issues" most people have
with Twisted. It will have many more bugs than Twisted (all the ones Twisted
had and fixed, sometimes very obscure and hard-to-find bugs), it will not be
significantly less complex (Twisted is as complex as it is because it had to
be, to do what it is supposed to do) and it will not require any less of a
brain-warp to understand (because that's just what event-driven programming
takes.)

If I wasn't short on free time (spending most of it on Py3k and, soon,
py3k-forward-compatibility) I would do all the necessary Twisted-integration
work myself :-)
-- 
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/20070214/837bdc7c/attachment.html