[Python-ideas] Tulip / PEP 3156 (original) (raw)

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

Guido van Rossum guido at python.org
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 protocolfactory() call and the connectionmade() call, as long as the future returned by createconnection() isn't marked done until the connectionmade() 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 "connectionmade" 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)

More information about the Python-ideas mailing list