Add --color-palette option to pyreverse

[DudeNr33]

Type of Changes

	Type
✓	✨ New feature
✓	🔨 Refactoring

Description

• Add support for user-defined color palettes
• Use a new default color palette, that is (hopefully) more visually pleasing and more accessible for color blind people. This palette is pretty close to what seaborn uses in their colorblind palette (see here)

The new default colors look like this:

Closes #6738

[codecov]

Codecov Report

Merging #8223 (64e68b5) into main (4cbabc9) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8223   +/-   ##
=======================================
  Coverage   95.45%   95.45%           
=======================================
  Files         177      177           
  Lines       18635    18661   +26     
=======================================
+ Hits        17788    17813   +25     
- Misses        847      848    +1     

Impacted Files	Coverage Δ
pylint/pyreverse/main.py	93.02% <100.00%> (+0.16%)	⬆️
pylint/pyreverse/writer.py	100.00% <100.00%> (ø)
pylint/testutils/pyreverse.py	98.07% <100.00%> (+0.07%)	⬆️
pylint/checkers/variables.py	97.29% <0.00%> (-0.09%)	⬇️
pylint/checkers/nested_min_max.py	100.00% <0.00%> (ø)
pylint/checkers/refactoring/refactoring_checker.py	98.33% <0.00%> (ø)
pylint/checkers/imports.py	94.33% <0.00%> (+0.04%)	⬆️
pylint/checkers/utils.py	95.83% <0.00%> (+0.06%)	⬆️

[nickdrozd]

Defaults looks great. Tested input color flag; works. 🎨

[Pierre-Sassoulas]

Maybe we should keep what we had because it's a kind of breaking change. I'm so not the person to tell you if the default color palette looks good or not... But now that it can be user defined then it's fine, user can change it to taste :)

[nickdrozd]

Maybe we should keep what we had because it's a kind of breaking change. I'm so not the person to tell you if the default color palette looks good or not... But now that it can be user defined then it's fine, user can change it to taste :)

By that same logic, anyone who just has to have alice blue and antique white is also free to specify them! But somehow I have the feeling that few will actually choose those colors 😆

[Pierre-Sassoulas]

You'd be surprised, people get accustomed to thing and if it changes there's always someone complaining. https://imgs.xkcd.com/comics/workflow.png

[DudeNr33]

I don't have a strong opinion on changing the default colors.
We can leave them as they are, and change them in 3.0.

[Pierre-Sassoulas]

I'd prefer to minimize churn but I'm also ok if @nickdrozd feels strongly about changing the default :)

[DudeNr33]

I will leave it as it is currently (i.e. stick with the previous default colors and leave the TODO to switch for 3.0) and will take care of the spelling errors this evening.
Trying to install enchant yesterday resulted in a downwards spiral that made me update macOS. Sometimes you gotta love being a developer... 😅

[Pierre-Sassoulas]

Trying to install enchant yesterday resulted in a downwards spiral that made me update macOS. Sometimes you gotta love being a developer...

https://www.youtube.com/watch?v=AbSehcT19u0

[nickdrozd]

Sure, the default colors could be changed later, as part of the wider push for sane defaults. But they really should be changed. It's not just my opinion that default colors are bad; the SO post that prompted the color issue specifically mentions wanting to change the "faint blue color" to a darker one.

And it's not just about opinions. The new proposed colors are objectively better in terms of accessibility than the current defaults. Actually, the ugliness and the inaccessibility have the same root cause, which is that alice blue and antique white are both difficult to distinguish from each other and difficult to distinguish from a white background.

As an example, here is a package diagram generated by Pyreverse with the current colors:

[DudeNr33]

As a 3.0 version is probably not far away from what I understood (#7607 (comment)), let's not do a breaking change in 2.17 and just do it with the next major version.

Also as a side note, pyenchant with Apple Silicon is just a big oof. You need to install both Python and enchant as x86_64 version (which is possible by following their docs; you will afterwards find yourself impossible to run pylint ever again with the native arm64 version of Python, as it will always try to load the incompatible x86 binaries.

So I'll still have to rely on the CI for catching spelling problems. 😐

[github-actions]

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉

This comment was generated for commit 64e68b5