[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:13:45 CET 2013

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/subprocesstransport.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)

More information about the Python-ideas mailing list