Skip to content

can_colorize() ignores FORCE_COLOR/NO_COLOR/TERM when -E is set #127873

Closed
@hugovk

Description

@hugovk

Bug report

Bug description:

Using one of the FORCE_COLOR, NO_COLOR or TERM=dumb environment variables is ignored when you use Python with -E.

-E means:

Ignore all PYTHON* environment variables, e.g. PYTHONPATH and PYTHONHOME, that might be set.

The -E is stored in sys.flags.ignore_environment.

sys.flags.ignore_environment is used to ignore PYTHON_COLORS (correct) but it's also ignoring these other env vars (incorrect).

For example, this is not colourised, as expected:

❯ NO_COLOR=1 python3.13 -c 1/0
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    1/0
    ~^~
ZeroDivisionError: division by zero

image

However, NO_COLOR=1 is ignored when passing -E and the output has colour when it should not:

❯ NO_COLOR=1 python3.13 -E -c 1/0
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    1/0
    ~^~
ZeroDivisionError: division by zero

image

This bit needs updating:

cpython/Lib/_colorize.py

Lines 43 to 56 in 487fdbe

if not sys.flags.ignore_environment:
if os.environ.get("PYTHON_COLORS") == "0":
return False
if os.environ.get("PYTHON_COLORS") == "1":
return True
if "NO_COLOR" in os.environ:
return False
if not COLORIZE:
return False
if not sys.flags.ignore_environment:
if "FORCE_COLOR" in os.environ:
return True
if os.environ.get("TERM") == "dumb":
return False

CPython versions tested on:

3.13, 3.14

Operating systems tested on:

Linux, macOS, Windows

Linked PRs

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.13bugs and security fixes3.14bugs and security fixesstdlibPython modules in the Lib dirtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions