Dark-red coloured crash stack dump is very hard to read on a dark-themed terminal

[Alberth289346]

When there is a problem in the Python code that crashes the interpeter, like

def test_something():
    /boom   # syntax error

you get the following colored output:

Depending on the light from the environment, this is hard to impossible to read.

OS: Fedora 30, python package versions etc are in the schreenshot.

[gnikonorov]

I think that changing the red color only may be too specific to this case ( what happens if the color gets too light on some terminals ). How would everyone feel about a change disabling color altogether for output if a flag is passed?

( in any case I'd like to implement this, if that's ok with everyone )

[gnikonorov]

Spoke to soon, you can turn off color reporting with --color=no @Alberth289346

e.g.: python3 -m pytest --color=no my_test/

[Alberth289346]

Yep, found that too, but colour is nice as you can see something is off without actually reading the output.

I don't know why no-one has invented a terminal where you don't have this colour-crap for every program, but until that time, I guess the best solution is to allow configuring with the 16 colours of the universe rather than hard-code them.

That would likely end up with something like the LS_COLORS env variable
or a git config section

# http://stackoverflow.com/questions/12795790/how-to-colorize-git-status-output
# http://stackoverflow.com/questions/10998792/how-to-color-the-git-console-in-ubuntu
[color]
    status = auto
    diff = auto
    ui = auto

[color "status"]
    added = green
    changed = blue bold
    untracked = magenta bold
    deleted = cyan

[color "branch"]
    current = white
    local = yellow bold
    remote = green

[color "diff"]
    new = yellow bold
    old = blue bold

(And yes, my colours are awful, but it beats green and red and the problem isn't urgent enough to look for a more sane configuration.)

One step further would be to have multiple configurations for different backgrounds, but feels like overkill.

[gnikonorov]

I'm pretty new to this, so I'll defer this call to someone with more experience with pytest. Thoughts @nicoddemus?

[RonnyPfannschmidt]

Unlike git pytest has no global config, so we can't adopt that solution

[gnikonorov]

we could stick it in the [pytest] section of the ini file, no? Or would that be too bloated

[RonnyPfannschmidt]

Project level is not acceptable

[EmilStenstrom]

Here's another example running pytest under WSL. The dark purple is very hard to read, and I actually just read a one as a zero and wasted half an hour because of this:

One option could be to enhance the --color option to allow specifying all 16 slots there if needed. I think this would nicely solve the issues that people have with "this one color needs changing". It doesn't need a global config either.

Ideas for the syntax:

• --color=darkblue:red "Map darkblue to read"
• --color=1:red "Set color slot 1 to red"
• Others?

[The-Compiler]

@EmilStenstrom What you're seeing there is actually Pygment's code syntax highlighting - also see #7132 for that.

[michjnich]

@RonnyPfannschmidt Why is project level not acceptable? As colour-blind person that has problems with the current colour-scheme, the ability to change this config would be very valueable.

Of course, a global config would be preferred, a la git, but I also understand that would be a big deal. To that end, being able to override them at a project level would be fine with me - I could just have a copy/paste setup that I could re-use for each project: And if that lets me see text I can't currently see, then that's a big improvement over red on black text.

Side note: red on black is a very common problem for colourblind people. It also affects people with other vision deficiencies.

[RonnyPfannschmidt]

I'd propose a env var as a starting point, else all we do is that colorblind people can fix some projects manually

I can even see the upcoming mess of maintainers rejecting such changes

I do wonder if there is any standard we can build on

[The-Compiler]

I wonder if pytest is really the right place to fix this, though? All pytest does (at least outside of the syntax highlighting, not sure about that) is setting one of 16 colors, which are roughly defined by name (black/red/green/yellow/blue/magenta/cyan/white, and then "bright" versions thereof).

I feel like it's the job of the terminal emulator (or the user configuring it) to pick appropriate colors (as in RGB values) for those names, i.e. something which results in enough contrast and legibility. For reference, here's mine:

Granted, not the best contrast either, but something I find comfortable enough to read. The keywords in GitHub's syntax highlighting above are another example how "red on dark background" could be rendered:

Clearly the examples presented in the screenshots of earlier comments don't do a good job of producing readable output with those colors - but that is not specific to pytest and will affect any tool wanting to output something in red. Thus, if your terminal picks unreadable color combinations for something as common as "red on default background" (or you're colorblind and would thus like to replace red by something else entirely), why not do that at the level of the terminal emulator rather than avoiding red in every single tool you use?

[michjnich]

@RonnyPfannschmidt An env var override setting would be fine too, imho. And perhaps this is the simplest solution, as it would just default to what's already there if not set.

@The-Compiler I can't read that first image at all - it's basically invisible text to me.

I know I can change terminal settings, and in fact I do, the problem is, different things use different colours and colour combos, so if I change the value of "red" in the terminal to be eg. light orange, pytest might look fine, but some other utility might have yellow on red, which would then be yellow on light orange - yet another combo I couldn't see. Every time a different util that makes use of colour is used, it just adds to the complexity and reduces the chances of being able to find any combo of terminal settings that work for everything.

With git, I can set the colours for each text type in my .gitconfig without actually changing the meaning of "red", and potentially causing some colour conflict in another util.

Bottom line is, around 12% of people are colourblind. More are sight-impaired in some other way that can be impacted by poor colour choices. If you're curious about any particular colour combo, I can recommend https://whocanuse.com.

The only real solution that doesn't cause conflicts with other utils, is to allow users to override colour choices for each util individually.

[The-Compiler]

@michjnich I indeed didn't consider the case of the same color causing issues in other combinations. Apologies and thanks for the clarification and details!

[michjnich]

No problem. The effects of colour-blindness can be a tough thing to explain to people as well sometimes - and there's absolutely no reason you would ever have considered that if it's never caused you problems.

I do hope there's some solution to this though - the env var suggestion seems reasonable. Most people wouldn't even need to think about it and would just continue getting the default colours, but those of us that need it could set it up fairly easily :)

[nicoddemus]

So, if IIUC the final proposal is to:

1. Have an environment variable to control the color scheme.
2. Define roles for the colors, which users can then use in the environment vars.

An example using some roles:

PYTEST_COLOR_SCHEME=text:white;error:red;warning:yellow;ok:green

?

[RonnyPfannschmidt]

Currently the internals don't work in terms of that, so we need more like a mass p colors helpwr, and we should switch from color coded output to intent based output later

[nicoddemus]

Currently the internals don't work in terms of that, so we need more like a mass p colors helpwr, and we should switch from color coded output to intent based output later

Yep, didn't mention that in my original message because I wanted to focus on the user-facing feature, but you are definitely correct.

[nicoddemus]

Another question: how about syntax highlighting, how/if it is affected by PYTEST_COLOR_SCHEME?

[RonnyPfannschmidt]

As for eventual user facin intent conding, it shouldn't be a part of pytest but a library we can use, and everyone else as well

[RonnyPfannschmidt]

Pygments uses token types and color schemes, that can map to intents partially, needs experiments