Add output() helper function to subprocess module
The check_output() function of the subprocess module raises an exception if the process returns a non-zero exit status. This is inconvenient for commands such as grep that use the return status to indicate something other than success or failure. The check_call() function has a companion call(), but here is currently no non-checking companion for check_call(). How about adding one with a signature such as output(args) --> (status, output) -- Greg
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The check_output() function of the subprocess module raises an exception if the process returns a non-zero exit status. This is inconvenient for commands such as grep that use the return status to indicate something other than success or failure.
The check_call() function has a companion call(), but here is currently no non-checking companion for check_call(). How about adding one with a signature such as
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)? Is the object to the extra typing, or...? -n -- Nathaniel J. Smith -- https://vorpus.org
On Thu, Apr 4, 2019 at 7:12 PM Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The check_output() function of the subprocess module raises an exception if the process returns a non-zero exit status. This is inconvenient for commands such as grep that use the return status to indicate something other than success or failure.
The check_call() function has a companion call(), but here is currently no non-checking companion for check_call(). How about adding one with a signature such as
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)? Is the object to the extra typing, or...?
Or discoverability. If you want to run a subprocess and catch its output, you'll naturally reach for check_output, and it feels clunkier to have to use run() instead. +1 on adding a nice simple function, although I'm not 100% sold on the name "output". ChrisA
On Thu, Apr 4, 2019 at 8:02 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Chris Angelico wrote:
+1 on adding a nice simple function, although I'm not 100% sold on the name "output".
The idea is that output/check_output would go together like call/check_call.
Yeah, so I think that on balance it's probably the best choice, but as its own thing, it's a bit odd. subprocess.output("...") I'm, let's say, +1 on the idea in general, and +0.9 on calling it "output". ChrisA
On Thu, Apr 04, 2019 at 07:44:29PM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Apr 4, 2019 at 7:12 PM Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The check_output() function of the subprocess module raises an exception if the process returns a non-zero exit status. This is inconvenient for commands such as grep that use the return status to indicate something other than success or failure.
The check_call() function has a companion call(), but here is currently no non-checking companion for check_call(). How about adding one with a signature such as
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)? Is the object to the extra typing, or...?
Or discoverability. If you want to run a subprocess and catch its output, you'll naturally reach for check_output, and it feels clunkier to have to use run() instead.
+1 on adding a nice simple function, although I'm not 100% sold on the name "output".
get_output ?
ChrisA
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
Let’s please leave this alone. As Serhiy says run() covers everything. On Thu, Apr 4, 2019 at 3:03 AM Oleg Broytman <phd@phdru.name> wrote:
On Thu, Apr 04, 2019 at 07:44:29PM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Apr 4, 2019 at 7:12 PM Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <
greg.ewing@canterbury.ac.nz> wrote:
The check_output() function of the subprocess module raises an exception if the process returns a non-zero exit status. This is inconvenient for commands such as grep that use the return status to indicate something other than success or failure.
The check_call() function has a companion call(), but here is currently no non-checking companion for check_call(). How about adding one with a signature such as
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)? Is the object to the extra typing, or...?
Or discoverability. If you want to run a subprocess and catch its output, you'll naturally reach for check_output, and it feels clunkier to have to use run() instead.
+1 on adding a nice simple function, although I'm not 100% sold on the name "output".
get_output ?
ChrisA
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
This is probably the most common first use case someone has when trying to use subprocess for the first time and I think it has always been a bit of a wart that, given all the helpers and wrappers the subprocess module already has, it lacks one for that very obvious and common need. Yes, run() covers everything, but so does subprocess.Popen() itself. Helpers still help. On Thu, Apr 4, 2019 at 1:15 PM Guido van Rossum <guido@python.org> wrote:
Let’s please leave this alone. As Serhiy says run() covers everything.
On Thu, Apr 4, 2019 at 3:03 AM Oleg Broytman <phd@phdru.name> wrote:
On Thu, Apr 04, 2019 at 07:44:29PM +1100, Chris Angelico < rosuav@gmail.com> wrote:
On Thu, Apr 4, 2019 at 7:12 PM Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <
greg.ewing@canterbury.ac.nz> wrote:
The check_output() function of the subprocess module raises an exception if the process returns a non-zero exit status. This is inconvenient for commands such as grep that use the return status to indicate something other than success or failure.
The check_call() function has a companion call(), but here is currently no non-checking companion for check_call(). How about adding one with a signature such as
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)? Is the object to the extra typing, or...?
Or discoverability. If you want to run a subprocess and catch its output, you'll naturally reach for check_output, and it feels clunkier to have to use run() instead.
+1 on adding a nice simple function, although I'm not 100% sold on the name "output".
get_output ?
ChrisA
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspealma@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
Nathaniel Smith wrote:
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)?
Yes, but you need to do more than that to get the output as a string. This is the relevant part of the implementation of check_output(): process = Popen(stdout=PIPE, *popenargs, **kwargs) output, unused_err = process.communicate() retcode = process.poll() -- Greg
On Thu, Apr 4, 2019 at 1:59 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Nathaniel Smith wrote:
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)?
Yes, but you need to do more than that to get the output as a string. This is the relevant part of the implementation of check_output():
process = Popen(stdout=PIPE, *popenargs, **kwargs) output, unused_err = process.communicate() retcode = process.poll()
from subprocess import run, pipe p = run(["grep", "njs", "/etc/passwd"], stdout=PIPE) p.returncode 0 p.stdout b'njs:x:1000:1000:Nathaniel J. Smith,,,:/home/njs:/usr/bin/zsh\n'
I do think it's a bit weird that you write 'stdout=PIPE' to mean 'please capture stdout' – it's leaking an internal implementation detail across an abstraction boundary. But it's documented, and run() allows any combination of check=True/False, capturing stdout or not, and capturing stderr or not, without having to invent 8 different functions. -n -- Nathaniel J. Smith -- https://vorpus.org
04.04.19 11:59, Greg Ewing пише:
Nathaniel Smith wrote:
On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
output(args) --> (status, output)
Isn't this already available as: run(args, stdout=PIPE)?
Yes, but you need to do more than that to get the output as a string. This is the relevant part of the implementation of check_output():
process = Popen(stdout=PIPE, *popenargs, **kwargs) output, unused_err = process.communicate() retcode = process.poll()
check_output() is currently implemented (besides arguments checks and legacy support) as just run(..., stdout=PIPE, check=True).stdout For getting unchecked output you need just to omit check=True. run(..., stdout=PIPE).stdout I think that after adding run() there is no need in output().
participants (7)
-
Calvin Spealman -
Chris Angelico -
Greg Ewing -
Guido van Rossum -
Nathaniel Smith -
Oleg Broytman -
Serhiy Storchaka