[Python-ideas] [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

[Guido van Rossum]

On Fri, Dec 21, 2012 at 1:04 PM, Laurens Van Houtven <_ at lvh.cc> wrote:
> Looks reasonable to me :) Comments:
>
> create_transport "combines" a transport and a protocol. Is that process
> reversible? that might seem like an exotic thing (and I guess it kind of
> is), but I've wanted this e.g for websockets, and I guess there's a few
> other cases where it could be useful :)

If you really need this, it's probably best to start out doing this as
a nonstandard extension of an implementation. The current
*implementation* makes it simple enough, but I don't think it's worth
complicating the PEP. Working code might convince me otherwise.

> eof_received on protocols seems unusual. What's the rationale?

Well how else would you indicate that the other end did a half-close
(in Twisted terminology)? You can't call connection_lost() because you
might still want to write more. E.g. this is how HTTP servers work if
there's no Content-length or chunked encoding on a request body: they
read until EOF, then do their thing and write the response.

> I know we disagree that callbacks (of the line_received variety) are a good
> idea for blocking IO (I think we should have universal protocol
> implementations), but can we agree that they're what we want for tulip? If
> so, I can try to figure out a way to get them to fit together :) I'm
> assuming that this means you'd like protocols and transports in this PEP?

Sorry, I have no idea what you're talking about. Can you clarify?

I do know that the PEP is weakest in specifying how a coroutine can
implement a transport. However my plans are clear: ild the old tulip
code there's a BufferedReader; somehow the coroutine will receive a
"stdin" and a "stdout" where the "stdin" is a BufferedReader, which
has methods like read(), readline() etc. which return Futures and must
be invoked using yield from; and "stdout" is a transport, which has
write() and friends that don't return anything but just buffer stuff
and start the I/O asynchronous (and may try to slow down the protocol
by calling its pause() method).

> A generic comment on yield from APIs that I'm sure has been discussed in
> some e-mail I missed: is there an obvious way to know up front whether
> something needs to be yielded or yield frommed? In twisted, which is what
> I'm used to it's all deferreds; but here a future's yield from but sleep's
> yield?

In PEP 3156 conformant code you're supposed always to use 'yield
from'. The only time you see a bare yield is when it's part of the
implementation's internals. (However I think tulip actually will
handle a yield the same way as a yield from, except that it's slower
because it makes a roundtrip to the scheduler, a.k.a. trampoline.)

> Will comment more as I keep reading I'm sure :)

Please do!

-- 
--Guido van Rossum (python.org/~guido)