On Thu, 11 Aug 2016 at 10:23 Antoine Pitrou <antoine@python.org> wrote:
Hi,
However, I think we can safely say that the Python community has not effectively done this over our twenty-plus year lifetime.
I'd like to offer a couple remarks here:
1) implementing a protocol usually goes beyond parsing (which, it's true, can easily be done "sans IO").
Yes, but parsing the data is at least one of the steps that people have historically not factored out into a stand-alone library.
2) many non-trivial protocols are stateful, at least at the level of a single connection; the statefulness may require doing I/O spontaneously (example: sending a keepalive packet). You can partly solve this by having a lower layer implementing the stateless parts ("sans IO") and an upper layer implementing the rest above it, but depending on the protocol it may be impossible to offer an *entire* implementation that doesn't depend on at least some notion of I/O.
Also true. While this can either be handled by a state machine emitting keepalive events or simply telling people they may need to emit something, this doesn't detract from the fact that at least parsing the data off the wire can be done as a standalone project (making a state machine that works for the protocol w/o any I/O will vary from protocol to protocol).
3) the Protocol abstraction in asyncio (massively inspired from Twisted, of course) is a pragmatic way to minimize the I/O coupling of protocol implementations (and one of the reasons why I pushed for it during the PEP discussion): it still has some I/O-related elements to it (a couple callbacks on Protocol, and a couple methods on Transport), but in a way that makes ignoring them much easier than when using "streams", sockets or similar concepts.
Yep. Once again, no one is saying that a I/O-free approach to protocols will work in all situations, but it should be considered and in cases where it does work it's good to have and can be used with asyncio's ABCs. IOW you're totally right that I/O-free protocol libraries will not always work, but sometimes they do and people should thus consider structuring their libraries that way when it makes sense.