Nick Coghlan added the comment:
I've switched to using Vinay Sajip's "sarge" for my own subprocess invocation
needs, which uses a similar all-in-one "run" API (albeit quite a different
approach to capturing output).
Accordingly, I don't think there's anything useful to be done specifically in
Nick Coghlan added the comment:
Indeed, further discussion showed that what they were after was something more
along the lines of sarge.Capture:
http://sarge.readthedocs.io/en/latest/overview.html#main-features
That is, the ability to start the subprocess running in the background, and
Thomas Kluyver added the comment:
I still feel that having one function with various options is easier to explain
than three separate functions with awkward names and limited use cases (e.g. no
capturing output without checking the exit code). The tweeter you replied to
said he didn't like
Nick Coghlan added the comment:
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
Akira Li added the comment:
> setting "universal_newlines=True" switches to UTF-8 encoded text pipes
It uses locale.getpreferredencoding(False) encoding -- something like
cp1252,cp1251,etc on Windows, and UTF-8 on *nix with proper locale settings.
It is ASCII (C/POSIX locale default) if the
Nick Coghlan added the comment:
As long as I'm refactoring these docs, I may also take a look at adding some
notes about text vs binary handling, since that's still problematic as
described in http://bugs.python.org/issue6135
The default behaviour is binary pipes, and setting
Nick Coghlan added the comment:
For reference, http://bugs.python.org/issue13237 covers the original change to
emphasise the convenience functions over the full flexibility of Popen. The
intent behind that reorganisation was to make it straightforward to get started
with the module without
R. David Murray added the comment:
Just as a data point, I always found it confusing when viewing the subprocess
docs that I had to page past the 'convenience functions' to get to what I
consider to be the "real" docs, the docs for Popen. I rarely use the
convenience functions; I find it
Thomas Kluyver added the comment:
I'm obviously biased, but I find the 'high level convenience API' less
convenient than the run() function: there are three different functions for the
same basic operation, they're not clearly named (check_output is nothing to do
with checking output), and
Gregory P. Smith added the comment:
FWIW i consider the whole subprocess module doc to be pretty unapproachable and
in need of refactoring. Your suggestions sound like good ones. We should sit
down and make it sane at pycon.
--
nosy: +gregory.p.smith
Nick Coghlan added the comment:
Likely revised structure:
* Move the high level convenience API back to the first section under a
subheading like "Common operations"
* Give the new run() function its own subheading like "Flexible command
invocation"
* Move the exception definitions to the
New submission from Nick Coghlan:
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
12 matches
Mail list logo
