On Windows in both CommandPrompt and PowerShell, 1/0 becomes ←[31m1←[0m←[1;31m/←[0m←[31m0←[0m in the traceback. They need to be switched to interpret the ANSI codes (possible, I believe) or treated as 'dumb', at least for this purpose.

On Windows in both CommandPrompt and PowerShell, 1/0 becomes ←[31m1←[0m←[1;31m/←[0m←[31m0←[0m in the traceback. They need to be switched to interpret the ANSI codes (possible, I believe) or treated as 'dumb', at least for this purpose.

Will investigate how to properly set this up for windows. I know the more modern Windows terminal (https://apps.microsoft.com/detail/9N0DX20HK701?hl=en-gb&gl=US) handles this correctly. We may need to deactivate this unless that new terminal is detected

I think for the start I will look at WT_SESSION as discussed here: microsoft/terminal#1040. More complicated solutions are possible (rich does this here but I don't want to start using ctypes and complications when printing exceptions, so i want to keep this dumb as possible).

We can iterate afterwards if someone want to add support to detecting other (working) environments.

Or maybe we can expose some C calls to windows and check for ENABLE_VIRTUAL_TERMINAL_PROCESSING....

According to https://en.wikipedia.org/wiki/Windows_Terminal, the first stable release of Windows Terminal was 18 days ago. It can run Command Prompt, Powershell, WSL Bash, and more. It is becoming default on Win 11 and can be installed on up-to-date Win 10. I will see if either an option 'cumulative update preview' or the next monthly update (in a week) installs it.

Excellent idea. Based on my experience in trying to support this type of feature in various terminal themes for friendly-traceback, I think it would be helpful if the colors in

class _ANSIColors:
    RED = '\x1b[31m'
    BOLD_RED = '\x1b[1;31m'

could also be user-configurable via environment variables or some other method.

Excellent idea. Based on my experience in trying to support this type of feature in various terminal themes for friendly-traceback, I think it would be helpful if the colors in

class _ANSIColors:
    RED = '\x1b[31m'
    BOLD_RED = '\x1b[1;31m'

could also be user-configurable via environment variables or some other method.

Thanks a lot for the suggestion. I will consider it, but for the first version, I am going to center on getting the defaults right for most environments and then we can iterate to improve the situation in different systems.

@terryjreedy I have exposed a call to GetConsoleMode in the nt module and I am using that to check if the given terminal supports colors. Can you try to give it a go. Here are my local results:

powershell

windows terminal

Some Python programs use https://github.com/tartley/colorama for colour, and some others do the colour themselves but still depend on colorama just to call their colorama.init() helper function to initialise Windows:

https://github.com/tartley/colorama#initialisation

You could check what that does, or their newer colorama.just_fix_windows_console(): https://github.com/tartley/colorama/blob/136808718af8b9583cb2eed1756ed6972eda4975/colorama/initialise.py#L72

Some Python programs use https://github.com/tartley/colorama for colour, and some others do the colour themselves but still depend on colorama just to call their colorama.init() helper function to initialise Windows:

That seems to wrap stderr and stdout to translate between ANSI and whatever windows uses. Given that this is critical code (we are printing errors) I don't want to mess with the standard streams not call complicated code.

Also, it is not clear to me what will happen if the interpreter does this wrapping and then something else does it on top (notice the only reason they claim is safe to call multiple times is because they record global state). As mentioned before, I want to leave this as dumb as possible and the current solution that detects if is possible to use ANSI sequences seems to work nicely to detect when is safe to do.

Edit:

Also seems that the future for Windows is the "Windows terminal" that supports this out of the box.

With fresh update, after "Fix multiline output", tracebacks look normal (b/w, not ansi) in Python started in CommandPrompt and in Windows Console (when started from icon or Explorer).

Python-specific environment variables usually don't include underscores in their names (e.g. we have PYTHONWARNINGS, not PYTHON_WARNINGS). Should that apply here too, so the environment variable might be PYTHONCOLORS rather than PYTHON_COLORS?

@barneygale, if you look at the current makeup of PYTHON env variables, you'll notice we are currently changing this naming scheme. New variables have an underscore to improve readability. We leave old ones as is for backwards compatibility.

Ah ha! Thanks :)