[Python-ideas] asyncore: included batteries don't fit

Guido van Rossum guido at python.org
Mon Oct 8 17:34:29 CEST 2012


On Mon, Oct 8, 2012 at 4:10 AM, Floris Bruynooghe <flub at devork.be> wrote:
> On 8 October 2012 03:49, Guido van Rossum <guido at python.org> wrote:
>> My current goal is to see if it would be possible to come up with an
>> abstraction that makes it possible to write protocol handlers that are
>> independent from the rest of the infrastructure (e.g. transport,
>> reactor).
>
> This would be my ideal situation too and I think this is what PEP 3153
> was trying to achieve.  While I am an greenlet (eventlet) user I agree
> with the sentiment that it is not ideal to include it into the stdlib
> itself and instead work to a solution where we can share protocol
> implementations while having the freedom to run on a twisted reactor,
> tornado, something greenlet based or something in the stdlib depending
> on the preference of the developer.
>
> FWIW I have implemented the AgentX protocol based on PEP-3153 and it
> isn't complete yet (I had to go outside of what it defines).  It is
> also rather heavy handed and I'm not sure how one could migrate the
> stdlib to something like this.  So hopefully there are better
> solutions possible.

The more I think about this the more I think it will be really hard to
accomplish. I think we ought to try and go for goals that are easier
to obtain (and still useful) first, such as a common reactor/ioloop
specification and a "best practice" implementation (which may choose a
different polling mechanism depending on the platform OS) in the
stdlib. 3rd party code could then hook into this mechanism and offer
alternate reactors, e.g. integrated with a 3rd party GUI library such
as Wx, Gtk, Qt -- maybe we can offer Tk integration in the stdlib. 3rd
party reactors could also offer additional functionality, e.g.
advanced scheduling, threadpool integration, or whatever (my
imagination isn't very good here).

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list