Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Description
Bug summary
The "standard" matplotlib color semantics is that the strings"none"
and"None"
both mean fully transparent (as can be checked by mpl.colors.to_rgba); the objectNone
can sometimes be used to mark a fallback. Because the matplotlibrc format cannot distinguish betweenNone
and"None"
(due the use of unquoted strings), it normally uses "auto" or "inherit" to mark a fallback.
However,rcParams["legend.labelcolor"]
(a relatively recent introduction -- matplotlib 3.5) tries to use "None" as default, and as a result ends up having inconsistent behavior between"None"
and"none"
.
Code for reproduction
frompylabimport*rcdefaults()print(repr(rcParams["legend.labelcolor"]))# default is the string "None"rcParams["legend.labelcolor"]="None";plot([0,1],label="foo");legend()# labels are blackrcParams["legend.labelcolor"]="none";plot([0,1],label="foo");legend()# labels are transparentrcParams["legend.labelcolor"]=None;plot([0,1],label="foo");legend()# labels are black
Actual outcome
See above.
Expected outcome
"None" and "none" should mean the same (likely both should mean "transparent", not so much for usefulness but rather for consistency.
Additional information
I suspect trying to support the objectNone
as well here basically cannot be made to work (as long as matplotlibrc uses unquoted strings); the default should switch to be "auto" (or "inherit").
As a further point, the implementation of the rcParams validator_validate_color_or_linecolor
seems wrong:
elifisinstance(s,str)andlen(s)==6orlen(s)==8:# (1)stmp='#'+sifis_color_like(stmp):returnstmpifs.lower()=='none':# (2)returnNone
Likely parentheses are missing at (1); also (2) can never hold due to the len() check.
As a side point, 3 and 4-hex color codes ("abc(d)", meaning "#abc(d)", meaning "#aabbcc(dd)") are also not supported by rcParams (this is also the case for the more general _validate_color), even though the normal color machinery does support them. At least this should be documented; I don't know if this can actually be supported without introducing an ambiguity with named colors.
Operating system
macos
Matplotlib Version
3.9.0.dev1542+geb62d6951a
Matplotlib Backend
any
Python version
3.12
Jupyter version
no
Installation
git checkout