Skip to content
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

Make capsys more like stdio streams in python3. Resolves #1407. #2265

Closed
wants to merge 2 commits into from
Closed

Make capsys more like stdio streams in python3. Resolves #1407. #2265

wants to merge 2 commits into from

Conversation

asottile
Copy link
Member

Thanks for submitting a PR, your contribution is really appreciated!

Here's a quick checklist that should be present in PRs:

  • Target: for bug or doc fixes, target master; for new features, target features;

Unless your change is trivial documentation fix (e.g., a typo or reword of a small section) please:

  • Make sure to include one or more tests for your change;
  • Add yourself to AUTHORS;
  • Add a new entry to CHANGELOG.rst
    • Choose any open position to avoid merge conflicts with other PRs.
    • Add a link to the issue you are fixing (if any) using RST syntax.
    • The pytest team likes to have people to acknowledged in the CHANGELOG, so please add a thank note to yourself ("Thanks @user for the PR") and a link to your GitHub profile. It may sound weird thanking yourself, but otherwise a maintainer would have to do it manually before or after merging instead of just using GitHub's merge button. This makes it easier on the maintainers to merge PRs.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.005%) to 92.704% when pulling ce1e7c9 on asottile:capture_has_buffer_property_py3 into 21a09f0 on pytest-dev:master.

@asottile
Copy link
Member Author

This seems to break python3.3, which is a bit perplexing! Lemme see if I can't figure out why (though python3.3 is getting pretty old (end of lifed in 2014)).

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.005%) to 92.704% when pulling f6d5651 on asottile:capture_has_buffer_property_py3 into 21a09f0 on pytest-dev:master.

@asottile
Copy link
Member Author

Neat: I fixed py33 by making pytester also use _pytest.capture instead of py.io. It seems there was a mysterious refcounting bug that only affects python3.3 that py.io was tickling.

@The-Compiler
Copy link
Member

Not sure if this should go to features instead.

@asottile
Copy link
Member Author

Is it not a bug that capsys incorrectly mocks stdout / stderr (why I decided to PR master)?

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.002%) to 92.707% when pulling 8091184 on asottile:capture_has_buffer_property_py3 into 21a09f0 on pytest-dev:master.

@The-Compiler
Copy link
Member

It probably is - however, it seems to me like there's quite some potential of breakage in some corner-cases here (like the one you already saw above 😉), and we're trying to avoid regressions in patch releases. History shows that usually, something weird ends up breaking without the pytest testsuite catching it, as pytest has a lot of users 😉

However, I don't have any strong feelings about this - let's see what others think.

@flub
Copy link
Member

flub commented Feb 19, 2017

Looks fine to me.

@nicoddemus
Copy link
Member

@asottile could you please take a look at the Windows tests?

I agree with @The-Compiler that we should merge this into features instead, for the reasons he mentioned.

@asottile
Copy link
Member Author

Fixed windows, it seems a little silly to be afraid to release bug fixes but it's not my project so I'll do as you please. I'm currently blocked on this fix, when is your next release?

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.002%) to 92.707% when pulling 95c356f on asottile:capture_has_buffer_property_py3 into 6680cb9 on pytest-dev:master.

@nicoddemus
Copy link
Member

Hmm can you provide an example which demonstrates the problem without the fix?

@RonnyPfannschmidt do you think this should go into features or it could go into master?

@asottile
Copy link
Member Author

There's a couple in my original issue: #1407

f = capture.CaptureIO()
# In python3, stdout / stderr are text io wrappers (exposing a buffer
# property of the underlying bytestream).
getattr(f, 'buffer', f).write(b'foo\n')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it'd pass even if the object doesn't have a buffer attribute (i.e. without any code changes).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

>>> import io
>>> f = io.StringIO()
>>> getattr(f, 'buffer', f).write(b'foo\n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument expected, got 'bytes'

Nope! Thankfully io.StringIO requires text (the prior implementation)

@asottile
Copy link
Member Author

I found a workaround with capfd. This can go into features instead. I'll close this in favor of my other PR

@asottile asottile closed this Feb 22, 2017
@asottile asottile deleted the capture_has_buffer_property_py3 branch February 22, 2017 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants