The general idea seems that matplotlib encourages a lot of third party packages to spawn in the wild, each with one or more colormaps, and each registering their colormaps via thecm module. Because there is easily some overlap between those to be expected (package 1 has "rocket", "moon" and "silveraqua", package 2 has "rocket" and "desertnight", user needs to import both because they need "silveraqua" and "desertnight"), there should be a solution that allows both packages to be imported without error. Even the warning might be annoying, in case "rocket" from package 1 and "rocket" from package 2 are in fact identical.

Perhaps we should just not use string names and instead use normal qualified python names (mypackage.mycmap)...

edit to clarify: If you're going to need an import to trigger the registration, you already have the module imported, so it's just as good to access an attribute from that module; because module names are unique (in a flat namespace), this handles the problem of name collision for us.
... and, per@jklymak's comment below, now you don't even need to have a registration API.

As a meta comment, I mess w colormaps all the time and don’t ever bother registering them. But maybe that’s because I’ve never bothered to set up my own startup package. Agree w@ImportanceOfBeingErnest that being able to override colormap names should be allowed. If I want to replace jet with turbo and call it jet, why not?

Overall, what is the end-user interface for colormaps? We really could use documentation on this. Are we all supposed to have our own pip installable packages myplottingsettings ? This feeds into the python matplotlibrc question

In order to not be misunderstood here: I did not say one should allow for matplotlib's colormaps to be overridden. In fact a protection layer like the one proposed in this PR makes perfect sense. My comment above was about not protecting additional/external colormaps; or at least find a solution for the case that several packages try to register the same colormap under the same name.

Flake8:

./lib/matplotlib/cm.py:30:1: E302 expected 2 blank lines, found 1

Moved to new doc scheme and took@dstansby 's completion of the sentence.

Where do we stand on this in light of#16943 and other discussions in the meeting?

This is orthogonal to#16943. While#16943 addresses modification of the default colormap objects, this here addresses replacing default colormap objects.

This has three approvals - just needs a rebase?

If one of the original reviewers had a minute to re-review, I think that would be adequate to merge.

Sorry, I'll explicitly ping because I'm not sure that re-requests show up in folks' feeds:@dopplershift@timhoffm@dstansby Thanks!

ok, fixed and squashed down to 3 non-embarrassing commits (I was apparently working a bit longer than my brain was useful last night...).

Hi all, I recently got bitten by this change (my fault for not keeping my CI images up to date with the latest matplotlib). I am curious about the use ofoverride_builtin option. Is this going to be removed in a future version of matplotlib, or can I rely on using it?

I maintain aMRI image viewer which comes with a collection of built in colour maps that, for historical reasons, use the same names as some built-in matplotlib colour maps, and am wondering about the best way to tackle this change in matplotlib. Thanks!

@pauldmccarthy At this point I think you can rely on it being there, but re-affirm the note in the docstring "please only use this if you are sure you need it"!

@tacaswell Yes, that particular note is why I was asking :)

I'd thought of working around this by "salting" my own colour maps with a unique prefix, but I maintain my own colourmap registry (just containing the colour maps specific to my application) alongsidematplotlib.cm, and have a fair amount of code which assumes that the identifiers are the same in both registries. So I was hoping to, at the very least, delay having to re-factor things. Generally my project is used as a stand-alone application, so there is not much of a concern in conflicting with other libraries that also usematplotlib.cm.register_cmap. But I will probably revisit this at some point to do things a bit more cleanly. Thanks for the reply :)

That makes sense in the context of an application. "historical reasons" is something I have great personal sympathy with :)