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:
On Sun, Oct 7, 2012 at 5:52 PM, Guido van Rossum <guido@python.org> wrote:
On Sat, Oct 6, 2012 at 9:09 PM, Duncan M. McGreggor <duncan.mcgreggor@gmail.com> wrote:
We're here ;-)
I'm forwarding this to the rest of the Twisted cabal...
Quick question. I'd like to see how Twisted typically implements a protocol parser. Where would be a good place to start reading example code?
I'm not exactly sure what you're looking for (e.g., I'm not sure what your exact definition of a protocol parser is), but this might be getting close to what you want:
* https://github.com/twisted/twisted/blob/master/twisted/mail/pop3.py * https://github.com/twisted/twisted/blob/master/twisted/protocols/basic.py
The POP3 protocol implementation in Twisted is a pretty good example of how one should create a protocol. It's a subclass of the twisted.protocol.basic.LineOnlyReceiver, and I'm guessing when you said "parsing" you're wanting to look at what's in the dataReceived method of that class.
Hopefully that's what you were after...
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:
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. Regards, Floris
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)
participants (2)
-
Floris Bruynooghe -
Guido van Rossum