Skip to content
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

Update colormap usage documentation to prioritize string colormap names #29028

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Kaustbh
Copy link
Contributor

@Kaustbh Kaustbh commented Oct 27, 2024

Fixes: #28915

This update suggests using string colormap names directly for cmap arguments due to their readability and ease of use. The update also recommends plt.colormaps[name] to retrieve colormap instances, offering a scalable approach that supports both built-in and user-registered colormaps.

Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Kaustbh Sorry, I have not been clear on the intended change in #28915.

With the recommendation

So the recommendation would be:

  • Use str colormap names on cmap arguments.
  • Use plt.colormaps[name] to get the colormap instance.

I primarily intended to change the way we access colormaps in the documentation; i.e. demonstrate by example. The concrete action is: "Go through our docs and apply these rules."

I'm a bit torn whether it's worth to spell the recommendations out explicitly for the user. While it gives direction, it's one more think to read/learn. Also, there's no canonical place to put that recommendation. It certainly does not belong in the diverging_colormaps what's new entry - that link was only where I saw the plt.cm* use.

@Kaustbh
Copy link
Contributor Author

Kaustbh commented Oct 28, 2024

Okay, I will give it a try.

@Kaustbh
Copy link
Contributor Author

Kaustbh commented Dec 3, 2024

Hi @timhoffm while going through the documentation I saw an example, https://matplotlib.org/stable/gallery/mplot3d/imshow3d.html#sphx-glr-gallery-mplot3d-imshow3d-py, in this example code,
we are using colors = plt.get_cmap(cmap)(norm(array)), when I changed it to colors = plt.colormaps[cmap](norm(array)), I was getting the error,

raise KeyError(f"{item!r} is not a known colormap name") from None

KeyError: 'None is not a known colormap name'

which caused because we are having cmap=None in the imshow3d function, how should I solve this problem.
And should I work on changing all the occurences in the docs?

@timhoffm
Copy link
Member

timhoffm commented Dec 3, 2024

Please leave this as is for this PR - it’s off-topic.

(General note: plt.get_cmap() will continue to be valid and is an alias of matplotlib.colormaps.get_cmap(), which in contrast to item access resolves None to the default colormap.)

@Kaustbh
Copy link
Contributor Author

Kaustbh commented Dec 3, 2024

Thank you for the clarification! I understand that plt.get_cmap() will remain valid and resolve None to the default colormap. I wanted to confirm: should I proceed with replacing all occurrences of plt.cm.* with the recommended syntax (cmap="name" or plt.colormaps[name]) as part of this PR?

@timhoffm
Copy link
Member

timhoffm commented Dec 3, 2024

should I proceed with replacing all occurrences of plt.cm.* with the recommended syntax (cmap="name" or plt.colormaps[name]) as part of this PR?

Yes.

@github-actions github-actions bot added topic: mplot3d Documentation: plot types files in galleries/plot_types Documentation: examples files in galleries/examples labels Dec 8, 2024
@Kaustbh Kaustbh requested a review from timhoffm December 8, 2024 08:25
@Kaustbh
Copy link
Contributor Author

Kaustbh commented Dec 8, 2024

I have made the commit please review and suggest me any changes.

lib/matplotlib/tests/test_image.py Outdated Show resolved Hide resolved
galleries/users_explain/colors/colorbar_only.py Outdated Show resolved Hide resolved
galleries/examples/showcase/mandelbrot.py Show resolved Hide resolved
doc/users/next_whats_new/diverging_colormaps.rst Outdated Show resolved Hide resolved
Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost good to go. Please still fix the flake8/precommit errors. - The failing test on OSX is unrelated.

@timhoffm
Copy link
Member

Pre commit isort fails. I don’t see directly what is wrong in the code. Can you please check what code changes it suggests?

@QuLogic
Copy link
Member

QuLogic commented Dec 17, 2024

Why are 132 files changed? Please don't changed unrelated files.

@Kaustbh
Copy link
Contributor Author

Kaustbh commented Dec 17, 2024

I think it happened because of isort . command, can you please tell how can I fix this?

@timhoffm
Copy link
Member

I assume, you have triggered isort locally and added all changes it has found? While I don't know why there are that many changes (maybe an update to isort?) these should not be part of this PR. We only want changes that are necessary in the context of this PR.

Before your last force-push there have been two or three isort errors in the precommit action. Please do the following:

  1. go back to that state (use git reflog if necessary)
  2. apply only the necessary isort changes for this PR. To do so, either:

@rcomer
Copy link
Member

rcomer commented Dec 17, 2024

pre-commit is configured to only run isort on three galleries

- repo: https://github.com/pycqa/isort
rev: 5.13.2
hooks:
- id: isort
name: isort (python)
files: ^galleries/tutorials/|^galleries/examples/|^galleries/plot_types/

@rcomer
Copy link
Member

rcomer commented Dec 19, 2024

If I have understood, all your deliberate changes are under galleries and all your non-deliberate changes are under lib. If that is correct, I think you can revert without resorting to reflogs:

git checkout HEAD~1 lib

This checks out the lib directory from the commit before the current one (HEAD~1).

@@ -39,7 +39,7 @@
t = Affine2D().scale(skill).rotate_deg(takeoff)
m = MarkerStyle(SUCCESS_SYMBOLS[mood], transform=t)
ax.plot(pos[0], pos[1], marker=m, color=cmap(thrust))
fig.colorbar(plt.cm.ScalarMappable(norm=Normalize(0, 1), cmap=cmap),
fig.colorbar(plt.cm.ScalarMappable(norm=Normalize(0, 1), cmap="plasma"),
Copy link
Member

@QuLogic QuLogic Dec 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now the cmap variable in unused here, but still on the line above, so you should change cmap instead of this line.

@@ -104,19 +104,19 @@ def bullseye_plot(ax, data, seg_bold=None, cmap="viridis", norm=None):

# Set the colormap and norm to correspond to the data for which
# the colorbar will be used.
cmap = mpl.cm.viridis
cmap = mpl.colormaps["viridis"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cmap is now unused, and should be removed (as well as the comment about it.)

cax=axs[0].inset_axes([0, -.15, 1, .1]),
orientation='horizontal', label='Some units')


# And again for the second colorbar.
cmap2 = mpl.cm.cool
cmap2 = mpl.colormaps["cool"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also unused and should be deleted.

@@ -108,7 +108,7 @@ def test_double_register_builtin_cmap():


def test_colormap_copy():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is about the Colormap class; you should not be replacing it with strings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation: examples files in galleries/examples Documentation: plot types files in galleries/plot_types topic: mplot3d
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Doc]: Preferred way of specifying colormaps via cmap
4 participants