-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
subprocess: unreliability of returncode not clear from docs #45010
Comments
The docs for the subprocess module (http://docs.python.org/lib/node533.html) give the impression that you can reliably find the return code of a process by checking returncode: -------- But in fact, returncode is only updated when the poll() method is called, and therefore will often be out-of-date. For instance >>> process=subprocess.Popen('true') #*nix command to do nothing
>>> process.returncode
>>> process.returncode==None
True
>>> process.poll()
0
>>> process.returncode
0 As far as I can see, it is always better to use poll() to check the status or return code of a subprocess. It might be good to either remove returncode from the docs entirely, or at least to explain that it won't always be correct. [incidentally, having returncode/poll() give None for a running process, and 0 for a process that has exited successfully, seems like a recipe for generating bugs. But I guess it's too late to do anything about that now] |
What wording would you rather see in the subprocess docs? |
Thanks for the reply, Collin. Perhaps something like: Alternatively, would it be possible to leave it out completely [and move the explanation of what return codes mean up into the description of poll()]? I can´t imagine many situations where it is a good idea to check returncode directly, and as I understand it the module documentation only covers variables that are useful to the outside world. |
Thanks for the report, fixed the documentation in r59777. |
Note this is closed but there is an open issue that is also a duplication of this issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: