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

2016-05-17 Thread Nick Coghlan
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

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

2015-04-26 Thread Berker Peksag
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: commit review - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___ ___

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

2015-04-25 Thread Thomas Kluyver
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 rep...@bugs.python.org http://bugs.python.org/issue23342

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

2015-04-25 Thread Gregory P. Smith
Changes by Gregory P. Smith g...@krypto.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___

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

2015-04-14 Thread Thomas Kluyver
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. -

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

2015-04-14 Thread Roundup Robot
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 ___

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

2015-04-14 Thread Gregory P. Smith
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 rep...@bugs.python.org http://bugs.python.org/issue23342

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

2015-04-08 Thread Thomas Kluyver
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 rep...@bugs.python.org http://bugs.python.org/issue23342

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

2015-04-08 Thread Gregory P. Smith
Gregory P. Smith added the comment: I'm at pycon as well, we can get this taken care of here. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___

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

2015-04-08 Thread Thomas Kluyver
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 rep...@bugs.python.org http://bugs.python.org/issue23342

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

2015-03-20 Thread Berker Peksag
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___

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

2015-03-19 Thread Thomas Kluyver
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 rep...@bugs.python.org

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

2015-03-19 Thread Martin Panter
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

2015-03-02 Thread Thomas Kluyver
Thomas Kluyver added the comment: Is there anything further I should be doing for this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___

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

2015-02-20 Thread Thomas Kluyver
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 rep...@bugs.python.org http://bugs.python.org/issue23342

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

2015-02-18 Thread R. David Murray
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

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

2015-02-10 Thread Thomas Kluyver
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

2015-02-09 Thread Thomas Kluyver
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

2015-02-09 Thread Martin Panter
Martin Panter added the comment: Have you seen the code review comments on the Rietveld, https://bugs.python.org/review/23342? (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 least

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

2015-02-09 Thread Jeff Hammel
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

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

2015-02-09 Thread Thomas Kluyver
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 rep...@bugs.python.org http://bugs.python.org/issue23342

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

2015-02-09 Thread Thomas Kluyver
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

2015-02-06 Thread Chris Rebert
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___ ___ Python-bugs-list

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

2015-02-02 Thread Thomas Kluyver
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

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

2015-01-31 Thread Thomas Kluyver
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

2015-01-31 Thread Martin Panter
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

2015-01-31 Thread Martin Panter
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

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

2015-01-28 Thread Thomas Kluyver
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

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

2015-01-28 Thread Ethan Furman
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 rep...@bugs.python.org http://bugs.python.org/issue23342

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

2015-01-28 Thread Gregory P. Smith
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

2015-01-28 Thread Martin Panter
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___ ___ Python-bugs-list

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

2015-01-28 Thread R. David Murray
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___ ___

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

2015-01-28 Thread Gregory P. Smith
Changes by Gregory P. Smith g...@krypto.org: -- assignee: - gregory.p.smith nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___

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

2015-01-28 Thread Thomas Kluyver
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,

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

2015-01-28 Thread Barry A. Warsaw
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___ ___ Python-bugs-list mailing

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

2015-01-28 Thread Thomas Kluyver
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

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

2015-01-28 Thread Ethan Furman
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23342 ___ ___ Python-bugs-list

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

2015-01-28 Thread Gregory P. Smith
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 the