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 object None
can sometimes be used to mark a fallback. Because the matplotlibrc format cannot distinguish between None
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
from pylab import *
rcdefaults()
print(repr(rcParams["legend.labelcolor"]))
# default is the string "None"
rcParams["legend.labelcolor"] = "None"; plot([0, 1], label="foo"); legend()
# labels are black
rcParams["legend.labelcolor"] = "none"; plot([0, 1], label="foo"); legend()
# labels are transparent
rcParams["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 object None
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:
elif isinstance(s, str) and len(s) == 6 or len(s) == 8: # (1)
stmp = '#' + s
if is_color_like(stmp):
return stmp
if s.lower() == 'none': # (2)
return None
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