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 akira, docs@python, gregory.p.smith, ncoghlan, r.david.murray, takluyver
Date 2016-11-14.05:13:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1479100415.33.0.795007419691.issue27050@psf.upfronthosting.co.za>
In-reply-to
Content
The introduction of run() and its presentation as the preferred interface has effectively reversed much of the progress that had been made in actually making the subprocess module approachable for the simplest use cases like https://twitter.com/fuzzychef/status/798025538237382656 (i.e. the exact case that "subprocess.call()" handles)

It does make sense to have run() as an intermediate tier of complexity between the base trio of call/check_call/check_output, and the full configurability of Popen, so it isn't the introduction of the API itself that's problematic, just the way we're currently presenting it.
History
Date User Action Args
2016-11-14 05:13:35ncoghlansetrecipients: + ncoghlan, gregory.p.smith, r.david.murray, docs@python, akira, takluyver
2016-11-14 05:13:35ncoghlansetmessageid: <1479100415.33.0.795007419691.issue27050@psf.upfronthosting.co.za>
2016-11-14 05:13:35ncoghlanlinkissue27050 messages
2016-11-14 05:13:34ncoghlancreate