-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdout capturing breaks sys.stdout.encoding #4389
Labels
Comments
blueyed
added a commit
to blueyed/pytest
that referenced
this issue
Nov 15, 2018
1 task
Thanks for the report. |
blueyed
added a commit
to blueyed/pytest
that referenced
this issue
Nov 15, 2018
blueyed
added a commit
to blueyed/pytest
that referenced
this issue
Nov 15, 2018
blueyed
added a commit
to blueyed/pytest
that referenced
this issue
Nov 16, 2018
blueyed
added a commit
to blueyed/pytest
that referenced
this issue
Feb 11, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
py.test by default replaces
sys.stdout
with something that captures test output, which is great! But the replacement stdout doesn't have a correctencoding
attribute, and that can break the code under test.(Prior to Python 3.6
sys.stdout.encoding
is the only way to figure out the current OEM encoding on Windows, which you need if you have to decode the output of subprocesses. You can see what happens when people try to use py.test on such code here: mgedmin/check-manifest#92)Here's a reproducible test case for Linux (note that you need to use Python 3.5 or older):
This is similar to #2375, except I'm not using the
capsys
fixture.The text was updated successfully, but these errors were encountered: