Question

Questions about Python’s subprocess.Popen() objects
(Please assume a scenario where the number of bytes being generated for stdout/stderr does not fill up the OS pipe buffers and create a deadlock waiting for the OS pipe buffers to accept more data)

1) Does it matter what order p.stdout.read() and p.wait() are in?

2) Does read() on a stdout/stderr subprocess.PIPE block until the process has terminated?

3) Are the stdout/stderr subprocess.PIPE file objects and data available even after the process has terminated?

import subprocess
process = subprocess.Popen(args="ls", stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
stdout = process.stdout.read()
# Does the above read() block until the process has terminated?
stderr = process.stderr.read()
return_code = process.wait()

process = subprocess.Popen(args="ls", stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
return_code = process.wait() 
# Are stdout and stderr pipes available now, even after the process terminated?
stdout = process.stdout.read()
stderr = process.stderr.read()

Answer 1

Q: Does it matter what order p.stdout.read() and p.wait() are in?
A: No.

Q: Does read() on a stdout/stderr subprocess.PIPE block until the process has terminated?
A: If no limit on the number of bytes to read is specified, then it will block until the stream is closed (which is likely when the process terminates).

Q: Are the stdout/stderr subprocess.PIPE file objects and data available even after the process has terminated?
A: Yes.

You may want to pay special attention to this warning from the subprocess documentation:

Warning: This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that.