[Python-Dev] A question about the subprocess implementation

Vinay Sajip vinay_sajip at yahoo.co.uk
Sun Jan 8 02:48:54 CET 2012

Terry Reedy <tjreedy <at> udel.edu> writes:

> The behavior matches the doc: Popen.stdin
> If the stdin argument was PIPE, this attribute is a file object that 
> provides input to the child process. Otherwise, it is None.

Right, but it's not very helpful, nor especially intuitive. Why does it have to
be None in the case where you pass in a file object? Is there some benefit to be
gained by doing this? Does something bad happen if you store that file object in
proc.stdin / proc.stdout / proc.stderr?

> I believe you are expected to keep a reference to anything you pass in.

This can of course be done, but it can make code less clear than it needs to be.
For example, if you run a subprocess asynchronously, the code that makes the
Popen constructor call can be in a different place to the code that e.g.
captures process output after completion. For that code to know how the Popen
was constructed seems to make coupling overly strong.

> That seems like a possibly reasonable enhancement request. But the
> counterargument might be that you have to separately keep track of the
> need to close anyway.

It may be that the close() needs to be called whether you passed PIPE in, or a
file-like object - (a) because of the need to receive and handle SIGPIPE in
command pipelines, and (b) because it's e.g. set to a pipe you constructed
yourself, and you need to close the write end before you can issue an unsized
read on the read end. So the close logic would have to do e.g.

if proc.stdout is None:
    # pull out the reference from some other place and then close it

rather than just


It's doable, of course. The with construction you suggested isn't usable in the
general case, where the close() code is in a different place from the code which
fires off the subprocess.

Of course, since the behaviour matches the docs it would be an enhancement
request rather than a bug report. I was hoping someone could enlighten me as to
the *reason* for the current behaviour ... as it is, subprocess comes in for
some stick in the community for being "hard to use" ...


Vinay Sajip

More information about the Python-Dev mailing list