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.

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

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.

That came up for termcolor and we replaced:

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

With:

# Then check system:ifos.environ.get("TERM")=="dumb":returnFalseifnothasattr(sys.stdout,"fileno"):returnFalsetry:returnos.isatty(sys.stdout.fileno())exceptio.UnsupportedOperation:returnsys.stdout.isatty()

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

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.

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

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", line4376, intest_colorized_detection_checks_for_environment_variablesself.assertEqual(traceback._can_colorize(),False)~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^AssertionError:True != False

Does it also need@force_not_colorized?

Hi. With this change, I am seeking several failures like the following one intest_traceback andtest_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", line959, intest_env_var_invalidself.check_env_var_invalid(nframe)~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^  File"/..../pythonmain/cpython-main/Lib/test/test_tracemalloc.py", line953, incheck_env_var_invalidself.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, andlibpython3.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

I will look into this today!

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