Many tests fail if FORCE_COLOR environment variable is set

[AlexWaygood]

Bug report

Bug description:

If you run FORCE_COLOR=1 make test, many tests fail. The failing tests are mostly due to tests which assert the contents of a traceback not expecting traceback to be colorised, but if you pass FORCE_COLOR=1, it seems like Python obediently colorises all traceback.

The full list of failing tests on my machine is:

20 tests failed:
    test.test_inspect.test_inspect test_capi test_cmd_line
    test_cmd_line_script test_compileall test_doctest test_eof
    test_exceptions test_idle test_interpreters test_regrtest
    test_repl test_runpy test_signal test_sys test_threading
    test_traceback test_tracemalloc test_unicodedata test_warnings

test_signal and test_ssl seem to fail on my machine without FORCE_COLOR being set, however, so those are probably unrelated.

Attached is the full output from running ./python.exe -E -m test_traceback -v (which is too long to paste into this issue body directly).

test_traceback.txt

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

[AlexWaygood]

(cc. @pablogsal for colorised tracebacks)

[gpshead]

python -E is defined as only ignoring PYTHON* environment variables. This is a good thing. https://docs.python.org/3/using/cmdline.html#cmdoption-E

I believe tests either need to be happy in the presence of arbitrary color control codes (barfing rainbows...), or our make test aka python -m test aka regrtest runner should explicitly un-configure the community standard not language specific COLOR variables.

[gpshead]

everyone else seems to be discussing on the other issue #112730, so i suggest others do the same.

[AlexWaygood]

PRs to fix this issue have also been linked to #112730, so I'll just close this as a duplicate 👍

(But I insist on claiming credit for raising the issue in the first place ;)