[Python-Dev] A question about the subprocess implementation
vinay_sajip at yahoo.co.uk
Sun Jan 8 03:06:33 CET 2012
Mike Meyer <mwm <at> mired.org> writes:
> Since the only reason they exist is so you can access your end of a
> pipe, setting them to anything would seem to be a bug. I'd argue that
> their existence is more a pola violation than them having the value
> None. But None is easier than a call to hasattr.
I don't follow your reasoning, re. why setting them to a handle used for
subprocess output would be a bug - it's logically the same as the PIPE case. For
example, I might have a pipe (say, constructed using os.pipe()) whose write end
is intended for the subprocess to output to, and whose read end I want to hand
off to some other code to read the output from the subprocess. However, if that
other code does a read() on that pipe, it will hang until the write handle for
the pipe is closed. So, once the subprocess has terminated, I need to close the
write handle. The actual reading might be done not in my code but in some client
code of my code. While I could use some other place to store it, where's the
problem in storing it in proc.stdout or proc.stderr?
> You can close the object you passed in if it wasn't PIPE. If you
> passed in PIPE, the object has to be exposed some way, otherwise you
> *can't* close it.
Yes, I'm not disputing that I need to keep track of it - just that proc.stdout
seems a good place to keep it. That way, the closing code can be de-coupled from
the code that sets up the subprocess. A use case for this is when you want the
subprocess and the parent to run concurrently/asynchronously, so the proc.wait()
and subsequent processing happens at a different time and place to the kick-off.
More information about the Python-Dev