[Twisted-Python] Event queue in the Python std lib

[Bob Ippolito]

On Jul 1, 2005, at 8:24 AM, Glyph Lefkowitz wrote:

> Itamar Shtull-Trauring wrote:
>
>> On Fri, 2005-07-01 at 10:56 +0100, Matt Goodall wrote:
>>
>
>
>> One solution is a separate Twisted package you can install,  
>> overriding
>> the stdlib's. Since Twisted, even split up, is quite large, this  
>> would
>> probably be necessary for most non-trivial functionality anyway,  
>> which
>> leads to:
>>
>
> IMHO the point here is the trivial functionality.  As far as I can  
> tell from the few examples of event-driven applications that I use  
> which I didn't write :-), there is a progression that many event- 
> driven Python programs go through these days:
>
>     - Implement something with asyncore
>     - realize asyncore's deficiencies, start enhancing it
>     - discover Twisted, re-implement networking code (from scratch)
>
> If the event loop in Python provided similar interfaces to the one  
> in Twisted, the amount of work involved in stage 3 could be greatly  
> reduced.

A fringe benefit of having something reactor-like in the Python  
stdlib is that it gives Twisted more credibility (amongst those that  
don't already know that we're right).

>> 3. Limited usefulness of minimal APIs: lets say we add Twisted to the
>> stdlib. Because it's large, we don't want to add *everything*. We  
>> can't
>> add SSL probably cause that depends on pyOpenSSL which is LGPLed,
>> probably don't want the pygtk reactor because that occasionally needs
>> updates for new pygtk releases, etc.. So Jane User decides to build a
>> network application, plays a bit with the TCP client code, and now  
>> says
>> "OK great, now to add a GUI and TLS support" - and suddenly she  
>> needs to
>> install the full Twisted framework to do that.
>>
>
> Right.  But, her code uses Twisted-like interfaces so she doesn't  
> have to re-write it all.  Given that a lot of network applications  
> are trivial one-offs, this step will not always happen.

If something like threadedselectreactor made it into stdlib, then GUI  
integration (and integration with otherwise blocking code) would be  
easy enough.

Personally, since this is the 2.5+ timeframe we're talking about  
here, I would rather see something PEP-342 based on the outside, as  
that would require less brain enhancement for most people to use  
properly.

Deferreds are just as important as anything else.. I mean hell, I  
have implemented the Deferred API (with cancellation) in both  
JavaScript and ActionScript 2.0 for various purposes because it's the  
Right Way to represent that sort of thing given the language  
constraints.

(the JavaScript stuff, which should make a lot of Pythonistas very  
happy, will probably make it into open source in 2 weeks or so.. the  
AS2 stuff I have no immediate plans of releasing).

-bob