bug: Importing colors from plumbum adds a trailing line to the output

[pawamoy]

It seems like merely importing colors from plumbum while setting FORCE_COLOR to supported values 1, 2, 3 and 4 adds a new line to a Python script output. Any other value (0, 5, 6, -1, "", "hello") do not trigger this behavior.

cd $(mktemp -d)
python -m venv .venv
. .venv/bin/activate
pip install plumbum rich

cat <<EOF >colors_without_plumbum.py
from rich.console import Console
console = Console()
console.print("[bold green]Hello[/]")
EOF

cat <<EOF >colors_with_plumbum.py
from plumbum import colors
from rich.console import Console
console = Console()
console.print("[bold green]Hello[/]")
EOF

cat <<EOF >colors.sh
echo "NOT forcing colors without Plumbum import"
python colors_without_plumbum.py | cat -n
echo "NOT forcing colors with Plumbum import"
python colors_with_plumbum.py | cat -n
echo "Forcing colors without Plumbum imports"
FORCE_COLOR=1 python colors_without_plumbum.py | cat -n
echo "Forcing colors with Plumbum imports"
FORCE_COLOR=1 python colors_with_plumbum.py | cat -n
EOF

bash colors.sh

The % comes from my Zsh prompt. If we redirect the output to a file and open it, here are the contents:

�[1;32mHello�[0m
�[0m

Without the Plumbum import, contents are:

�[1;32mHello�[0m

So actually, rather than a newline, it seems to append a reset sequence. Now that the line is not empty, cat displays it. It has no newline character at the end so my prompt is directly printed after it.

• System: Linux
• Python: 3.11.5
• Plumbum: 1.8.2
• Rich: 13.6.0

[pawamoy]

Testing all values, and printing with cat -v:

for value in -1 0 1 2 3 4 5 "" yes no; do
    FORCE_COLOR="${value}" python colors_with_plumbum.py > fc$value.txt
done

% for fc in fc*; do echo $fc:; cat -v $fc; echo; done
fc0.txt:
^[[1;32mHello^[[0m

fc-1.txt:
^[[1;32mHello^[[0m

fc1.txt:
^[[1;32mHello^[[0m
^[[0m
fc2.txt:
^[[1;32mHello^[[0m
^[[0m
fc3.txt:
^[[1;32mHello^[[0m
^[[0m
fc4.txt:
^[[1;32mHello^[[0m
^[[0m
fc5.txt:
^[[1;32mHello^[[0m

fcno.txt:
^[[1;32mHello^[[0m

fc.txt:
^[[1;32mHello^[[0m

fcyes.txt:
^[[1;32mHello^[[0m

[pawamoy]

Hmmm, this is caused by atexit.register(_reset) in plumbum.colors. IIUC this is a guard rail to always reset everything (colors, styles, etc.) before giving back control to the parent process (the shell usually). Could maybe this guardrail not be added at import time, but deferred later, if Plumbum color functionality is actually used? Or could we maybe have a "trust" option (in the form of an environment variable) to disable the atexit registration? I'd prefer the first solution though, as it wouldn't require setting yet another environment variable.

[henryiii]

I was really worried about breaking prompts, but I think that's not as bad these days. In 3.13 Python will even fix the REPL for you if color leaks. Maybe we can remove it and have an opt-in function that adds the protection instead.

[pawamoy]

That would be great @henryiii, thanks 🙂