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

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Feb 15 03:47:39 CET 2007

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

More information about the Python-Dev mailing list