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?