On Fri, Dec 21, 2012 at 1:04 PM, Laurens Van Houtven <_...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
