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

[Greg Ewing]

Steve Holden wrote:

> If the borrowed code takes a reactor parameter then presumably the 
> top-level code can pass the appropriate reactor type in.

Since there should only be one reactor at a time in
any given application, it shouldn't have to be passed
in -- it could be held in a global variable deep
inside the library. Only the code which creates the
reactor initially needs to know about that variable,
or even that there is such a thing as a reactor.

> "Incorporating some piece of event-driven code written by someone else" 
> implies specific assumptions about event types and delivery, surely.

It requires agreement on how to specify the event types
and what to do in response, but that's all it should
require.

The way I envisage it, setting up an event callback
should be like opening a file -- there's only one way
to do it, and you don't have to worry about what the
rest of the application is doing. You don't have to
get passed an object that knows how to open files --
it's a fundamental service provided by the system.
You just use it.

> That's why it's difficult to port code between GUI toolkits, for 
> example, and even more so to write code that runs on several toolkits 
> without change.

Just in case it's not clear, the events I'm talking
about are things like file and socket I/O, not GUI
events. Trying to use two different GUIs at once is
not something I'm addressing.

Rather, you should be able to write code that does
e.g. some async socket I/O, and embed it in a GUI
app using e.g. gtk, without having to modify it to
take account of the fact that it's working in a
gtk environment, or having to parameterise it to
allow for such things.

> You seem to be arguing for libraries that contain platform dependencies 
> to handle multiple platforms.

I'm arguing that as much of the platform dependency
as possible should be in the asyncore library (or
whatever replaces it). The main application code
*might* have to give it a hint such as "this app
uses gtk", but no more than that. And ideally, I'd
prefer it not to even have to do that -- pygtk
should do whatever is necessary to hook itself
into asyncore if at all possible, not the other
way around.

> Since Glyph has already stated his opinion that Twisted isn't yet ready 
> for adoption as-is this doesn't add to the discussion.

Okay, but one of the suggestions made seemed to be
"why not just use the Twisted API". I'm putting
forward a possible reason.

--
Greg