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

[Guido van Rossum]

On Sun, Jan 20, 2013 at 2:53 PM, Andrew Bennetts <andrew at bemusement.org> wrote:
> Guido van Rossum wrote:
> […]
>> I have a more-or-less working but probably incomplete version checked
>> into the tulip repo:
>> http://code.google.com/p/tulip/source/browse/tulip/subprocess_transport.py
>>
>> Note that this completely ignores stderr -- this makes the code
>> simpler while still useful (there's plenty of useful stuff you can do
>> without reading stderr), and avoids the questions Greg Ewing brought
>> up about needing two transports (one for stdout, another for stderr).
>
> Although 3 pipes to a subprocess (stdin, stdout, stderr) is the usual
> convention, it's not the only possibility, so that configuration
> shouldn't be hard-coded.  On POSIX some programs can and do make use of
> the ability to have more pipes to a subprocess; e.g. the various *fd
> options of gnupg (--status-fd, --logger-fd, --command-fd, and so on).
> And some programs give the child process file descriptors that aren't
> pipes, like sockets (e.g. an inetd-like server that accepts a socket
> then spawns a subprocess to serve it).

Hm. I agree that something to represent an arbitrary pipe or pair of
pipes may be useful occasionally, and we need to have an
implementation that can deal with stdout and stderr separately anyway,
but I don't think such extended configurations are common enough that
we need to completely generalize the API. I think it is fine to follow
the example of subprocess.py, which allows but does not encourage
extra pipes and treats stdin, stdout and stderr differently.

> So I hope tulip will support these possibilities (although obviously the
> stdin/out/err style should be the convenient default).  You will be
> unsurprised to hear that Twisted does :)
>
> (Please forgive me if this was already pointed out.  It's hard keeping
> up with python-ideas.)

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