Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
182afa1 toa2d9e63Comparea2d9e63 to0ab0843Compare| @@ -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 todfb2f68CompareThere 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.
| Thecolorforinvalidvalues (NaNormasked). | |
| Thecolorforinvalidvalues (NaNormasked). | |
| ..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 thebad, under, over colors can already be set upon creation.
dfb2f68 toe1adce7Compare0a0b9ac intomatplotlib:mainUh oh!
There was an error while loading.Please reload this page.
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.