Re: [Python-ideas] asyncore: included batteries don't fit
On Sun, Oct 7, 2012 at 7:16 PM, Duncan McGreggor <duncan.mcgreggor@gmail.com> wrote:
Yes, those are perfect. The term I used came from one of Josiah's previous messages in this thread, but I think he really meant protocol handler. 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). I honestly have no idea if this is a sane idea but I'm going to look into it anyway; if it works it would be cool to be able to reuse the same POP3 logic in different environments (e.g. synchronous thread-based, Twisted) without having to pul in all of Twisted. I.e. Twisted could contribute the code to the stdlib and the stdlib could make it work with SocketServer but Twisted could still use it (assuming Twisted ever gets ported to Py3k :-). -- --Guido van Rossum (python.org/~guido)
On 8 October 2012 03:49, Guido van Rossum <guido@python.org> wrote:
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. Regards, Floris
On Mon, Oct 8, 2012 at 4:10 AM, Floris Bruynooghe <flub@devork.be> wrote:
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)
On 8 October 2012 03:49, Guido van Rossum <guido@python.org> wrote:
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. Regards, Floris
On Mon, Oct 8, 2012 at 4:10 AM, Floris Bruynooghe <flub@devork.be> wrote:
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)
participants (2)
-
Floris Bruynooghe -
Guido van Rossum