On Mon, Oct 8, 2012 at 4:10 AM, Floris Bruynooghe <flub@devork.be> wrote:
On 8 October 2012 03:49, Guido van Rossum <guido@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)