nghung270192 / colorama

Automatically exported from code.google.com/p/colorama
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

colorama shouldn't wrap stdout/stderr if they are None #61

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I know the user could actually check before doing this, but I think 
colorama.init() should not wrap anything if the initial streams are None. This 
happens with an executable which is frozen on Windows for example.

If they are None, colorama will break things like "if sys.stderr is not None 
and sys.stderr.isatty()". Since it can't do anything meaningful *anyways*, it 
should just leave them as None.

I had this issue because of a library which calls colorama.init() at import 
time: https://github.com/borntyping/python-colorlog/issues/13

Original issue reported on code.google.com by m...@the-compiler.org on 25 Aug 2014 at 8:42

GoogleCodeExporter commented 9 years ago
Thanks for the report. Makes sense.

I've been putting off colorama fixes for a long time due to not using Windows 
these days. I'll see if I can get it together enough to find a Windows box and 
try out a fix to this and other issues.
Best, -Jonathan aka tartley

Original comment by tart...@gmail.com on 26 Aug 2014 at 11:04

GoogleCodeExporter commented 9 years ago
(Somehow the CSS is not rendered here so this page is somewhat unusable, I hope 
this comes through).

I just opened a pull request here: https://github.com/tartley/colorama/pull/14

All the test still pass (and I added a new one), and the demos look good as 
well.

Original comment by m...@the-compiler.org on 26 Aug 2014 at 11:51

GoogleCodeExporter commented 9 years ago
Fixed by submission from github user The-Compiler.

We now safely handle the case where stdin or stderr are None on startup (e.g. 
if running from a .pyw or something)

Original comment by tart...@gmail.com on 3 Sep 2014 at 7:58