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

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

Guido van Rossum guido at python.org
Fri Jan 18 01:19:35 CET 2013

On Thu, Jan 17, 2013 at 3:44 PM, Paul Moore <p.f.moore at gmail.com> wrote:

On 17 January 2013 19:10, Guido van Rossum <guido at python.org> wrote:

I think it would be tremendously helpful if you tried to implement the UNIX version of the subprocess transport. (Note that AFAIK Twisted has one of these too, maybe you can get some implementation ideas from them.) You were right. In starting to do so, I found out that my thinking has been solely based on a callback style of programming (users implement protocol classes and code the relevant "data received" methods themselves). From looking at some of the sample code, I see that this is not really the intended usage style. At this point my head exploded. Coroutines, what fun! I am now reading the sample code, the section of the PEP on coroutines, and the mailing list threads on the matter. I may be some time :-) (The technicalities of the implementation aren't hard - it's just a datareceived type of protocol wrapper round a couple of pipes. It's the usability and design issues that matter, and they are strongly affected by "intended usage").

Right, this is a very good observation.

Paul

PS From the PEP, it seems that a protocol must implement the 4 methods connectionmade, datareceived, eofreceived and connectionlost. For a process, which has 2 output streams involved, a single datareceived method isn't enough. I see two options - having 2 separate protocol classes involved, or having a process protocol with a different interface. Neither option seems obviously best, although Twisted appears to use different protocol types for different types of transport. How critical is the principle that there is a single type of protocol to the PEP?

Not critical at all. The plan for UDP (datagrams in general) is to have different protocol methods as well.

TBH I would be happy with a first cut that only deals with stdout, like os.popen(). :-)

Note that I am intrigued by this problem as well and may be hacking up a version for myself in my spare time.

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

More information about the Python-ideas mailing list