[issue23342] run() - unified high-level interface for subprocess

Nick Coghlan added the comment: This change has made the subprocess docs intimidating and unapproachable again - this is a *LOWER* level swiss-army knife API than the 3 high level convenience functions. I've filed http://bugs.python.org/issue27050 to suggest changing the way this is documente

[issue23342] run() - unified high-level interface for subprocess

Changes by Berker Peksag : -- stage: commit review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23342] run() - unified high-level interface for subprocess

Changes by Gregory P. Smith : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: I expect this can be closed now, unless there's some post-commit review somewhere that needs addressing? -- ___ Python tracker ___

[issue23342] run() - unified high-level interface for subprocess

Gregory P. Smith added the comment: thanks! i'll close this later after some buildbot runs and any post-commit reviews. -- stage: patch review -> commit review ___ Python tracker _

[issue23342] run() - unified high-level interface for subprocess

Roundup Robot added the comment: New changeset f0a00ee094ff by Gregory P. Smith in branch 'default': Add a subprocess.run() function than returns a CalledProcess instance for a https://hg.python.org/cpython/rev/f0a00ee094ff -- nosy: +python-dev ___ Py

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: 6a following in-person review with Gregory: - Reapplied to the updated codebase. - Docs: mention the older functions near the top, because they'll still be important for some time. - Docs: Be explicit that combined stdout/stderr goes in stdout attribute. - Vari

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Great! I'm free after my IPython tutorial this afternoon, all of tomorrow, and I'm around for the sprints. -- ___ Python tracker ___ __

[issue23342] run() - unified high-level interface for subprocess

Gregory P. Smith added the comment: I'm at pycon as well, we can get this taken care of here. :) -- ___ Python tracker ___ ___ Python-

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: I am still keen for this to move forwards. I am at PyCon if anyone wants to discuss it in person. -- ___ Python tracker ___ ___

[issue23342] run() - unified high-level interface for subprocess

Changes by Berker Peksag : -- nosy: +berker.peksag stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Thanks, that was an oversight. Patch 5 adds CompletedProcess to __all__. -- Added file: http://bugs.python.org/file38574/subprocess_run5.patch ___ Python tracker __

[issue23342] run() - unified high-level interface for subprocess

Martin Panter added the comment: One thing that just popped into my mind that I don’t think has been discussed: The patch adds the new run() function to subprocess.__all__, but the CompletedProcess class is still missing. Was that an oversight or a conscious decision? --

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Is there anything further I should be doing for this? -- ___ Python tracker ___ ___ Python-bugs-list

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Can I interest any of you in further review? I think I have responded to all comments so far. Thanks! -- ___ Python tracker ___ ___

[issue23342] run() - unified high-level interface for subprocess

R. David Murray added the comment: string vs list: see issue 6760 for some background. Yes, I think it is an API bug, but there is no consensus for fixing it (it would require a deprecation period). Jeff: in general your points to do not seem to be apropos to this particular proposed enhance

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Jeff: This makes it somewhat easier to handle input and output as strings instead of streams. Most of the functionality was already there, but this makes it more broadly useful. It doesn't especially address your other points, but I'm not aiming to completely

[issue23342] run() - unified high-level interface for subprocess

Jeff Hammel added the comment: A few observations in passing. I beg your pardon for not commenting after a more in depth study of the issue, but as someone that's written and managed several subprocess module front-ends, my general observations seem applicable. subprocess needs easier and mor

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Fourth version of patch, responding to review comments on Rietveld. The major changes are: - Eliminated the corner case when passing input=None to run() - now it's a real default parameter. Added a shim in check_output to keep it behaving the old way in case

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Aha, I hadn't seen any of those. They had indeed been caught by the spam filter. I'll look over them now. -- ___ Python tracker ___ ___

[issue23342] run() - unified high-level interface for subprocess

Martin Panter added the comment: Have you seen the code review comments on the Rietveld, ? (Maybe check spam emails.) Many of the comments from the earlier patches still stand. In particular, I would like to see the “input” default value addressed, at leas

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Would anyone like to do further review of this - or commit it ;-) ? I don't think anyone has objected to the concept since I brought it up on python-ideas, but if anyone is -1, please say so. -- ___ Python tracker

[issue23342] run() - unified high-level interface for subprocess

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Third version of the patch (subprocess_run3): - Simplifies the documentation of the trio (call, check_call, check_output) to describe them in terms of the equivalent run() call. - Remove a warning about using PIPE with check_output - I believe this was already

[issue23342] run() - unified high-level interface for subprocess

Martin Panter added the comment: It’s okay to leave them as independent classes, if you don’t want multiple inheritance. I was just putting the idea out there. It is a similar pattern to the HTTPError exception and HTTPResponse return value for urlopen(). -- __

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Yep, they are pretty much equivalent to those, except: - check_call has a 'return 0' if it succeeds - add '.stdout' to the end of the expression for check_output I'll work on documenting the trio in those terms. If people want, some/all of the trio could also

[issue23342] run() - unified high-level interface for subprocess

Martin Panter added the comment: Maybe you don’t want to touch the implementation of the “older high-level API” for fear of subtly breaking something, but for clarification, and perhaps documentation, would the old functions now be equivalent to this? def call(***): # Verify PIPE not in (s

[issue23342] run() - unified high-level interface for subprocess

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue23342] run() - unified high-level interface for subprocess

Gregory P. Smith added the comment: Ethan: check_output combines them when stdout=subprocess.STDOUT is passed ( https://docs.python.org/3.5/library/subprocess.html#subprocess.STDOUT). Never pass stdout=PIPE or stderr= PIPE to call() or check*() methods as that will lead to a deadlock when a pipe

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Updated patch following Gregory's suggestions: - The check_returncode parameter is now called check. The method on CompletedProcess is still check_returncode, though. - Clarified the docs about args - CalledProcessError and TimeoutExceeded gain a stdout propert

[issue23342] run() - unified high-level interface for subprocess

Ethan Furman added the comment: I haven't checked the code, but does check_output and friends combine stdout and stderr when ouput=PIPE? -- ___ Python tracker ___ __

[issue23342] run() - unified high-level interface for subprocess

Gregory P. Smith added the comment: A 1) Opting not to capture by default is good. Let people explicitly request that. A 2) "check" seems like a reasonable parameter name for the "should i raise if rc != 0" bool. I don't have any other good bikeshed name suggestions. A 3) Calling it args th

[issue23342] run() - unified high-level interface for subprocess

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue23342] run() - unified high-level interface for subprocess

Changes by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mail

[issue23342] run() - unified high-level interface for subprocess

Thomas Kluyver added the comment: Another question: With this patch, CalledProcessError and TimeoutExceeded exceptions now have attributes called output and stderr. It would seem less surprising for output to be called stdout, but we can't break existing code that relies on the output attribut

[issue23342] run() - unified high-level interface for subprocess

Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue23342] run() - unified high-level interface for subprocess

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue23342] run() - unified high-level interface for subprocess

New submission from Thomas Kluyver: This follows on from the python-ideas thread starting here: https://mail.python.org/pipermail/python-ideas/2015-January/031479.html subprocess gains: - A CompletedProcess class representing a process that has finished, with attributes args, returncode, stdo