-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
[doc] subprocess module: Clarify kwarg handing for convenience APIs #74605
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
Comments
As per the discussion in #1685, the current nominal signatures of the convenience APIs in subprocess is confusing, as they don't make it clear that all Popen keyword arguments are supported, with only the most common ones being listed in the signature. Proposed fixes:
Background: The status quo is that while this behaviour is documented, it's documented solely as text in the bodies of the API definitions, using paragraphs like the following:
While it's technically anecdotal, we still have pretty decent evidence that this isn't adequate as:
The working theory behind adding the appropriately named |
For the curious, Nick added the “frequently used arguments” in bpo-13237. Before that the signatures were like <https://docs.python.org/release/3.2.2/library/subprocess.html#convenience-functions\>: subprocess.call(*popenargs, **kwargs) |
If you add “cwd” to Frequently Use Arguments, please try to keep the details in one place. Otherwise you encourage a fix for bpo-15533 (cwd platform specifics) to repeat the problem of bpo-20344 (args vs shell platform specifics), where some details are only found in one section and contradict the other section. |
The just merged PR covers the "list The rest of the proposed fixes are still pending a patch (and keeping in mind Martin's caveat on minimising duplication between the "Frequently Used Arguments" section and the full Popen documentation) |
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: