bpo-42388: Fix subprocess.check_output input=None when text=True#23467
Conversation
When the modern text= spelling of the universal_newlines= parameter was added for Python 3.7, check_output's special case around input=None was overlooked. So it behaved differently with universal_newlines=True vs text=True. This reconciles the behavior to be consistent and adds a test to guarantee it. The documentation already describes this check_output input=None behavior difference vs the other subprocess functions. This ensures that documented behavior remains accurate in all cases.
|
Would it also make sense to clarify the following sentence in the docs?
It's not clear to me whether I must not pass |
|
This PR is stale because it has been open for 30 days with no activity. |
|
Thanks @izbyshev, I've clarified the docs. |
izbyshev
left a comment
There was a problem hiding this comment.
Thanks! If I may nitpick, I suggest an even more clarified change :)
Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru>
|
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8, 3.9. |
…honGH-23467) When the modern text= spelling of the universal_newlines= parameter was added for Python 3.7, check_output's special case around input=None was overlooked. So it behaved differently with universal_newlines=True vs text=True. This reconciles the behavior to be consistent and adds a test to guarantee it. Also clarifies the existing check_output documentation. Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru> (cherry picked from commit 64abf37) Co-authored-by: Gregory P. Smith <greg@krypto.org>
|
GH-23934 is a backport of this pull request to the 3.9 branch. |
…honGH-23467) When the modern text= spelling of the universal_newlines= parameter was added for Python 3.7, check_output's special case around input=None was overlooked. So it behaved differently with universal_newlines=True vs text=True. This reconciles the behavior to be consistent and adds a test to guarantee it. Also clarifies the existing check_output documentation. Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru> (cherry picked from commit 64abf37) Co-authored-by: Gregory P. Smith <greg@krypto.org>
|
GH-23935 is a backport of this pull request to the 3.8 branch. |
…23467) When the modern text= spelling of the universal_newlines= parameter was added for Python 3.7, check_output's special case around input=None was overlooked. So it behaved differently with universal_newlines=True vs text=True. This reconciles the behavior to be consistent and adds a test to guarantee it. Also clarifies the existing check_output documentation. Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru> (cherry picked from commit 64abf37) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…23467) When the modern text= spelling of the universal_newlines= parameter was added for Python 3.7, check_output's special case around input=None was overlooked. So it behaved differently with universal_newlines=True vs text=True. This reconciles the behavior to be consistent and adds a test to guarantee it. Also clarifies the existing check_output documentation. Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru> (cherry picked from commit 64abf37) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…honGH-23467) When the modern text= spelling of the universal_newlines= parameter was added for Python 3.7, check_output's special case around input=None was overlooked. So it behaved differently with universal_newlines=True vs text=True. This reconciles the behavior to be consistent and adds a test to guarantee it. Also clarifies the existing check_output documentation. Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru>
When the modern text= spelling of the universal_newlines= parameter was added
for Python 3.7, check_output's special case around input=None was overlooked.
So it behaved differently with universal_newlines=True vs text=True. This
reconciles the behavior to be consistent and adds a test to guarantee it.
The documentation already described this check_output input=None behavior
difference vs the other subprocess functions, but it wasn't very clear to readers.
The documentation has been clarified as part of this.
https://bugs.python.org/issue42388