This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients ncoghlan
Date 2016-05-18.05:11:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
In-reply-to
Content
The new subprocess.run() API is a swiss-army-knife API like subprocess.Popen before it.

1. You have to pass a boolean toggle to indicate whether or not you want the return code checked
2. You have to pass magic constants to keyword arguments to indicate whether or not you want output captured
3. You have to understand and deconstruct a complex object in order to get useful information from it

By contrast, the *actual* high-level API encodes all those requests in the name of the function you call.

(This isn't a request to change anything functional, it's a request to undo the harm done to the subprocess documentation by backing away from the claim that this is a high level API on par with call, check_call and check_output - it's not, it's just not quite as low level as subprocess.Popen)
History
Date User Action Args
2016-05-18 05:11:45ncoghlansetrecipients: + ncoghlan
2016-05-18 05:11:45ncoghlansetmessageid: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
2016-05-18 05:11:45ncoghlanlinkissue27050 messages
2016-05-18 05:11:45ncoghlancreate