[Python-Dev] A question about the subprocess implementation (original) (raw)

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


Terry Reedy <tjreedy 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: proc.stdout.close() else: # pull out the reference from some other place and then close it

rather than just

proc.stdout.close()

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" ...

Regards,

Vinay Sajip



More information about the Python-Dev mailing list