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

[Steve Holden]

Greg Ewing 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.
> 
If the borrowed code takes a reactor parameter then presumably the 
top-level code can pass the appropriate reactor type in. If the borrowed 
code uses a fixed reactor then it's difficult to see how changes to the 
Twisted API could help.

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

> 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.
> 
You seem to be arguing for libraries that contain platform dependencies 
to handle multiple platforms. Glyph seems to prefer the ability for the 
library caller to pass in handlers for platform-dependent features.

> So at this point I'm skeptical that the Twisted
> API for these things should be adopted as-is.
> 
Since Glyph has already stated his opinion that Twisted isn't yet ready 
for adoption as-is this doesn't add to the discussion.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Blog of Note:          http://holdenweb.blogspot.com
See you at PyCon?         http://us.pycon.org/TX2007