ENH: Add bad, under, over kwargs to Colormap#29460
Conversation
timhoffm
force-pushed
the
colormap-bad-under-over
branch
from
182afa1 to
a2d9e63
Compare
timhoffm
force-pushed
the
colormap-bad-under-over
branch
from
a2d9e63 to
0ab0843
Compare
|
|
||
| the list will be extended by repetition. | ||
|
|
||
| .. deprecated:: 3.11 |
There was a problem hiding this comment.
This seems orthogonal to this PR? Or is this already deprecated elsewhere and this is just a doc cleanup? I'm not really following why we would need to do this.
There was a problem hiding this comment.
The deprecation is in #29135, it's indeed unrelated. I just noticed that I haven't added this to the parameter docs, and didn't bother to make a separate PR since I was editing that position in the docstring anyway. Sorry for the confusion.
timhoffm
force-pushed
the
colormap-bad-under-over
branch
from
0ab0843 to
dfb2f68
Compare
jklymak
left a comment
jklymak
left a comment
There was a problem hiding this comment.
I'm not 100% sure about immutability of colormaps, but this addition seems helpful even with the current state of things.
|
The annoying thing with mutable colormaps is that we always have to do copies when returning colormaps from the , because a user could do Changes to colormaps are relatively rare. The most prominent ones are over/under/bad, but again most of them are just setup-time changes (and done separately because the constructor did not supply them). Conceptually a colormap with a given name is fixed. You don't want it to behave differently at different. Therefore, immutability is logically helpful here, and immutable objects are much easier to maintain and reason about. |
| N : int | ||
| The number of RGB quantization levels. | ||
| bad : :mpltype:`color`, default: transparent | ||
| The color for invalid values (NaN or masked). |
There was a problem hiding this comment.
| The color for invalid values (NaN or masked). | |
| The color for invalid values (NaN or masked). | |
| .. versionadded:: 3.11 |
? (Likewise in many locations below. Hence, maybe it is not required...)
There was a problem hiding this comment.
Done. It's a bit verbose, but OTOH it's good to be explicit about this.
oscargus
left a comment
oscargus
left a comment
There was a problem hiding this comment.
Subject to deciding if the .. versionadded:: should be added. Feel free to self merge when you have decided.
This is part of the effort for making Colormaps immutable (matplotlib#29141). Obviously, we can only get immutable in the future if the bad, under, over colors can already be set upon creation.
timhoffm
force-pushed
the
colormap-bad-under-over
branch
from
dfb2f68 to
e1adce7
Compare
3 participants
This is part of the effort for making Colormaps immutable (#29141). Obviously, we can only get immutable in the future if the bad, under, over colors can already be set upon creation.