[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
> data_received 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
> connection_made, data_received, eof_received and connection_lost. For
> a process, which has 2 output streams involved, a single data_received
> 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