[Python-ideas] Tulip / PEP 3156 - subprocess events

Mon Jan 21 17:22:19 CET 2013

On Sun, Jan 20, 2013 at 11:52 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Jan 21, 2013 at 5:03 AM, Guido van Rossum <guido at python.org> wrote:
>> Anyway, I
>> think Nick is okay with the separation between the protocol_factory()
>> call and the connection_made() call, as long as the future returned by
>> create_connection() isn't marked done until the connection_made() call
>> returns. That's an easy fix in the current Tulip code. It's a little
>> harder though to fix up the PEP to clarify all this...
>> Right, I understand what the separate method enables now. I think one
> way to make it clearer in the PEP is to require that "connection_made"
> return a Future or coroutine, rather than being an ordinary method
> returning None.

Hm. This would seem to introduce Futures / coroutines at the wrong
level (I want to allow protocol implementers to use them, but not
require them). If connection_made() wants to initiate some blocking
I/O, it is free to do so, but it ought to wrap that in a Task. If the
class needs completion of this task to be a prerequisite for handling
data passed to a subsequent data_received() call, it will need to
devise some buffering and/or locking scheme that's outside the scope
of the PEP.
Note that I am also hoping to produce a more coroutine-oriented style
for writing protocols. The main piece of code for this already exists,
the StreamReader class
(http://code.google.com/p/tulip/source/browse/tulip/http_client.py?r=b1028ab02dc0f722d790aac4768663a972d9d555#37),
but I need to think about how to hook it all together nicely (for
writing, the transport's API is ready to be used by coroutines).
-- 
--Guido van Rossum (python.org/~guido)