-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
ENH: Add bad, under, over kwargs to Colormap #29460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
182afa1
to
a2d9e63
Compare
a2d9e63
to
0ab0843
Compare
@@ -1215,6 +1247,18 @@ class ListedColormap(Colormap): | |||
N > len(colors) | |||
|
|||
the list will be extended by repetition. | |||
|
|||
.. deprecated:: 3.11 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
0ab0843
to
dfb2f68
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
""" | ||
Parameters | ||
---------- | ||
name : str | ||
The name of the colormap. | ||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. It's a bit verbose, but OTOH it's good to be explicit about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
dfb2f68
to
e1adce7
Compare
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.