Support possibility to wrap either stdout or stderr

[barabanus]

It's common to use stdout to generate binary files and stderr to print log and errors. At the same time colorama provides very convenient functionality to strip color codes from streams when output is redirected. The problem is that colorama wraps both stdout and stderr which strips binary symbols from stdout when binary files are generated.

It would be very useful for colorama library to wrap separately stderr / stdout on demand during initialization. I suggest to reuse 'wrap' argument to colorama.init() like this:

colorama.init()
colorama.init(wrap=False)
colorama.init(wrap="stdout")
colorama.init(wrap="stderr")

This pull request is linked to issue #256

[tartley]

Hey. FYI, Yesterday I created a PR to test releases before we push them to PyPI. When that is merged, I'll be more confident about resuming merges and releases. I'll try to look at this PR soon. Thank you for creating it!

[septatrix]

I think I would prefer passing the streams directly instead of as strings such that the signature would be init(..., wrap: bool | TextIO) -> None instead.

[barabanus]

I think I would prefer passing the streams directly instead of as strings such that the signature would be init(..., wrap: bool | TextIO) -> None instead.

The only valid values for the stream argument would be either sys.stdout or sys.stderr, so I don't see any benefits to use stream vs string.

[tartley]

Forgive my very overdue drive-by review, but does this do the wrong thing if wrap==False ?

[tartley]

same as above

[tartley]

Also: This PR changes the code and behavior, but does not include corresponding test changes, which it would need before it could be merged. (or how else would future contributors know when their changes break your code?)

(I thought I mentioned this last night, but don't see it now. Perhaps I messed up.)

[barabanus]

Thanks for the comments, I'll review them on weekends