CC @nicoddemus

I approached this only from the capfd front, it's slightly more involved to implement this for capsys (because python2 capture io is not predictably typed) -- I think this is fine, capfd is more useful in this case anyway.

Feedback appreciated, I threw this together quickly and might've missed some documentation / naming / etc.

Thanks a lot @asottile, that was quick! 👍

it's slightly more involved to implement this for capsys (because python2 capture io is not predictably typed)

This is fine, but it is easy to implement capsys-like for Python 3? IMHO it is fine to add Python 3-only functionality if reasonably easy (doesn't depend on new syntax for example). Not sure how others feel about this, but it is time to start considering Python 3 only features when it is not feasible to support them in Python 2.

Yeah capsysbinary is pretty easy to implement in python 3 due to the work I did in #2266 (CaptureIO maintains .buffer), it's only difficult because in python2 CaptureIO is TextIO (backed by io.StringIO) which doesn't actually expose a binary storage.

Yeah capsysbinary is pretty easy to implement in python 3

I'm OK with making capsysbinary available only in Python 3. We should make it explicit in the docs and using the fixture in Python 2 should raise an error.

But let's see what others think about this first.

Coverage decreased (-0.003%) to 92.694% when pulling 123e4f6 on asottile:capfdbinary into 685387a on pytest-dev:features.

Coverage decreased (-0.002%) to 92.695% when pulling 8f90812 on asottile:capfdbinary into 685387a on pytest-dev:features.

we can start with python3 only, but we should take a look at exposing a encoded bytesio kinda thing in future

@asottile so I guess we can go ahead with capsysbinary for py3 only then. 👍

@nicoddemus cool, ok for me to do that in a followup?

@asottile yup

@RonnyPfannschmidt want some more time to take look at this?

Otherwise I will merge this tomorrow. 👍

Thanks again @asottile!