On Thu, 11 Aug 2016 at 10:23 Antoine Pitrou <anto...@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.
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
