Title: Add "capture_output=True" option to
Type: enhancement Stage: patch review
Components: Versions:
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: barry, gregory.p.smith, ncoghlan
Priority: normal Keywords: patch

Created on 2017-11-21 06:13 by ncoghlan, last changed 2018-01-11 13:51 by bbayles.

Pull Requests
URL Status Linked Edit
PR 5149 open bbayles, 2018-01-11 13:51
Messages (2)
msg306627 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-11-21 06:13
I'm hesitant to suggest adding yet-another-option to any subprocess API, but I'm thinking it may be worth it in this case.

The idea is to make it possible to replace:

    result =, stdout=PIPE, stderr=PIPE)


    result =, capture_output=True)

That way, it would be possible for the raw stdin/stdout/stderr parameters to be treated as low level implementation details most of the time, since the most common configurations would be:

    # Use parent's stdin/stdout/stderr
    result = 
    # Use pipe for stdin, use parent's stdout/stderr
    result =, input=data)
    # Use parent's stdin, use pipe for stdout/stderr
    result =, capture_output=True) 
    # Use pipe for stdin/stdout/stderr
    result =, input=data, capture_output=True)
msg306643 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2017-11-21 14:25
Yeah, I find it pretty common to set both stdout and stderr to PIPE, but I'm with you in hesitating to add YAO to the subprocess API.  If you do move forward with this though, I think capture_output would have to be mutually exclusive to stdout and stderr.  You should not be allowed to provide either of the latter two if the former is given.
Date User Action Args
2018-01-11 13:51:15bbaylessetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request5015
2017-11-21 14:25:37barrysetnosy: + barry
messages: + msg306643
2017-11-21 06:13:47ncoghlancreate