black
black copied to clipboard
Turn off color depending on PY_COLORS / NO_COLOR
Currently (black 22.1.0) it is not possible to turn off colored output, in particular in the summary at the end. Please provide a simple way to turn color off, preferably via one of the environment variables PY_COLORS or NO_COLOR.
Why should we provide this feature? What is the use case?
And where do you get these environment variable names from? Are they standardized in some way?
The use case it not wanting to see color on the command line, I find that distracting. Apart from that the line in white is completely unreadable on a light gray background (that one is completely useless, but to find out I needed extra effort).
The environment variables are used by various tools, see for example https://docs.pytest.org/en/6.2.x/reference.html#environment-variables
Would the colors (or forcing BW) be configurable for the shell itself? I'm not totally opposed to the idea, just asking what would be the most sensible thing to do.
I don't understand what you mean by "configurable for the shell itself". I like environment variables, because I can set them globally for me in my .bashrc. And to avoid playing whack-a-mole with every new tool I would like a variable like NO_COLOR that is not tool-specific, or PY_COLORS that at least could apply to all Python tools.
Sorry if I was unclear, and I'm no command-line wizard. But I'm under the impression that e.g. bash can be configured to be BW globally without the need for environment variables.
There are also dumb terminals which do not interpret ANSI escape sequences, instead showing them verbatim.
In my specific case, the env var is TERM=dumb
(emacs compilation buffer on Linux), and as compilation
, I am running first black
and then flake8
.
In the compilation buffer, lines like
foo/bar.py:23:42: F821 undefined name 'txt'
will be colored by the editor to show the foo/bar.py:23:42:
part and allow clicking on that part to jump to the proper place in the source file.
Unfortunately, directly above that line from flake8
will be
^[[1mAll done! ✨ 🍰 ✨^[[0m
^[[34m10 files ^[[0mleft unchanged.
which is not very readable.
FWIW, the workaround appears to be to tell black that its stderr is not a TTY:
black8 2>&1 | cat
@JelleZijlstra wrote:
What is the use case?
One use case is emacs compilation (noted above) as well as shell mode. There are many other cases where plain text is desirable. Many of these use cases involve automation. It is common to run language processing programs in a pseudo-tty where black
will produce colorized output even though the output is being parsed by a computer. In such environments, it's common to set TERM=dumb
.
And where do you get these environment variable names from? Are they standardized in some way?
See no-color.org for a proposed (de facto) standard.
There has been a standard for many decades called POSIX, which standardizes program behavior around the use of $TERM
. Most languages (including Python) provide utilities for colorizing output while respecting $TERM
.
I also have a problem with the use of colorized output. The readability of some of the text is poor, depending on the background color. For visually impaired people reading the output is a struggle.
@JelleZijlstra wrote:
Why should we provide this feature? What is the use case?
I was wondering this about the choice of using colorization. Why did you choose to provide this feature and what was your intended use case? The same goes to a large extent for the use of emoji, which have even less added value than the colorization, IMHO.
EDIT: language