Bug report
Bug description:
In order to ensure its tests are meaningful even if color is disabled, the TestColorized test object in test_argparse modifies _colorize.can_colorize during setup, but does not subsequently restore it to the original value. As a consequence, the rest of the test session is polluted with colors/color codes even if NO_COLOR=1, or when in a dumb terminal or pipe. By comparison, we can look at the output of a similar setup in test_regrtest that uses mock.patch to only affect the state in that one test.
Given:
Expected:
./python -m test test_regrtest -m TestColorized
Polluted visuals:
./python -m test test_argparse test_regrtest -m TestColorized
Polluted text:
./python -m test test_argparse test_regrtest -m TestColorized > OUTPUT.txt
less OUTPUT.txt
CPython versions tested on:
CPython main branch, 3.14
Operating systems tested on:
Linux
Linked PRs
Bug report
Bug description:
In order to ensure its tests are meaningful even if color is disabled, the
TestColorizedtest object intest_argparsemodifies_colorize.can_colorizeduring setup, but does not subsequently restore it to the original value. As a consequence, the rest of the test session is polluted with colors/color codes even ifNO_COLOR=1, or when in a dumb terminal or pipe. By comparison, we can look at the output of a similar setup intest_regrtestthat usesmock.patchto only affect the state in that one test.Given:
Expected:
Polluted visuals:
Polluted text:
CPython versions tested on:
CPython main branch, 3.14
Operating systems tested on:
Linux
Linked PRs
setUp/tearDownof_colorize.can_colorizeintest_argparse#135238