gh-112730: Make the test suite resilient to color-activation environment variables

[pablogsal]

• Issue: Use color to highlight error locations #112730

[gvanrossum]

I am kind of sad that the solution is to add a special hack to suppress color to every test that would break. My ideal solution would be to suppress the color variables when -E is used, or for the traceback code to be able to detect whether -E is used.

[pablogsal]

I am kind of sad that the solution is to add a special hack to suppress color to every test that would break. My ideal solution would be to suppress the color variables when -E is used, or for the traceback code to be able to detect whether -E is used.

That only takes half of the tests because that fixes the cases where the traceback is taken from a subprocess. The other half which is when the traceback is taken from the process that runs test itself you need the decorator because the test suite cannot be executed itself always with -E.

To be honest I am happy to go this route (ignore on -E) but as @gpshead had some concerns with that I went with the most general solution first

[gvanrossum]

Got it. I wonder if _can_colorize() is also a bit naive? Its default is to checking whether stderr is a tty, even when its caller is going to write to some other stream.

[hugovk]

That came up for termcolor and we replaced:

    return (
        hasattr(sys.stdout, "isatty")
        and sys.stdout.isatty()
        and os.environ.get("TERM") != "dumb"
    )

With:

    # Then check system:
    if os.environ.get("TERM") == "dumb":
        return False
    if not hasattr(sys.stdout, "fileno"):
        return False

    try:
        return os.isatty(sys.stdout.fileno())
    except io.UnsupportedOperation:
        return sys.stdout.isatty()

https://github.com/termcolor/termcolor/pull/56/files

[gpshead]

So long as the number of decorator applications isn't huge I think this works. We should pay attention to users during the alpha and beta cycle. I'm assuming they aren't likely to find issues with this in CI and they probably do not enable colors there. It feels more likely to happen to an end user developer working within their local dev environment (which I believe is how we found it amongst ourselves?)

[gpshead]

There's enough decorators in this test file I suggest just disabling it via setUpModule / tearDownModule instead.

[gpshead]

FWIW I do not mind if we just wind up disabling it entirely on -E, especially for the initial release of the feature. I agree that regardless of a PYTHON_ environment variable name prefix, it is a natural behavior change for people to look to -E and expect it to do.

[pablogsal]

Ok, I will move to disable on -E then and remove as many decorators as possible.

[hugovk]

This test is failing:

FAIL: test_colorized_detection_checks_for_environment_variables (test.test_traceback.TestColorizedTraceback.test_colorized_detection_checks_for_environment_variables)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\cpython\cpython\Lib\test\test_traceback.py", line 4376, in test_colorized_detection_checks_for_environment_variables
    self.assertEqual(traceback._can_colorize(), False)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: True != False

Does it also need @force_not_colorized?

[kulikjak]

Hi. With this change, I am seeking several failures like the following one in test_traceback and test_tracemalloc:

======================================================================
FAIL: test_env_var_invalid (test.test_tracemalloc.TestCommandLine.test_env_var_invalid) (nframe=-1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/..../pythonmain/cpython-main/Lib/test/test_tracemalloc.py", line 959, in test_env_var_invalid
    self.check_env_var_invalid(nframe)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
  File "/..../pythonmain/cpython-main/Lib/test/test_tracemalloc.py", line 953, in check_env_var_invalid
    self.fail(f"unexpected output: {stderr!a}")
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: unexpected output: b'ld.so.1: python: fatal: libpython3.13.so.1.0: open failed: No such file or directory\nld.so.1: python: fatal: relocation error: file /..../pythonmain/build/sparcv9/python: symbol Py_BytesMain: referenced symbol not found\n'

It seems that because the environment is now being cleared in those tests, LD_LIBRARY_PATH is no longer set in the subprocess, and libpython3.13.so.1.0 thus not found.

I am seeing this on Oracle Solaris, though atm I don't think this is specific to us? Also, I am executing the test suite in a pretty standard way:

cd /..../pythonmain/build/sparcv9; EXTRATESTOPTS="-v test_traceback test_tracemalloc" /usr/gnu/bin/make test

[pablogsal]

I will look into this today!

[ericsnowcurrently]

FWIW, I've seen failures in test_traceback/test_tracemalloc on a number of stable buildbots since this change.