colorama also handles tty detection so init() can be called unconditionally. But I guess there's no harm to check either.

There's also this: https://stackoverflow.com/questions/12492810/python-how-can-i-make-the-ansi-escape-codes-to-work-also-in-windows/60194390#60194390
Which seems to indicate with a few lines of code using ctypes we don't need colorama. It seems great but I wonder if colorama is providing us with something else valuable?

To follow up on my last comment, this https://stackoverflow.com/a/36760881 gives some more information. It seems that it's only turning on Windows' native ANSI-interpreter.

So the simple non-colorama code might not help people whose Windows doesn't have ANSI capabilities.

colorama also handles tty detection so init() can be called unconditionally. But I guess there's no harm to check either.

That's a good point. I think I will leave it in. If I read colorama's docs right, it's still trying to filter out all the color codes in a non-tty environment. So since we don't add the codes in the first place in the that case, I like not having to filter sys.stdout and sys.stderr at all.

Current Result on Windows:

Thanks for the independent test, @CarliJoy , that seems to work as expected, the codes still visible are fixed in the other PR.

colorama also handles tty detection so init() can be called unconditionally. But I guess there's no harm to check either.

Another possible option would just be to use colorama for everything--so the "color functions" would always add the color escape codes, and we rely on colorama to remove them if we're not in a tty.

I didn't go this route just out of conservatism (original code works) and because I have no idea how much overhead this would add.