I like this addition and would find it very useful.

I wonder ifget_cmap should also return a copy by default. I can imagine that would sufficiently API-breaking that we need to think hard about it. But aget_cmap function that accepts these params as well would be quite nice.

Alternatively one could argue thatget_cmap() gets you an existing colormap, and e.g. something likenew_colormap() gets you a copy of an existing one. This would allow the notably useful API to be incorporated without backwards compatibility issues,

 plt.cm.new_colormap("viridis", bad="white")

Initially I thought that changingget_cmap to return a copy would be too disruptive, but let's look at the various behavriors ofget_cmap:

• If it is called with a second argumentN, it's already returning a new (resampled) colormap anyways; so we don't even need to bother with a copy.
• If it is called with a string argument (and noN), it is returning a reference to one of the builtin colormaps. I would argue that these are intended to be immutable and that modifying them should be considered a bug. (Although I would readily admit that one can get away with modifying them in single use scripts.)
• If it is called with a colormap argument, it returns that colormap (without ever resampling it). If the call-site controls the argument, one may wonder why they additionally pass it throughget_cmap; if the argument comes from "outside", then it should likely be considered immutable as well.

Thus, I think modifyingget_cmap to return a copy is more likely to fix accidental modifications of builtin or custom cmaps rather than be disruptive.

On the other hand, I would say thatget_cmap(...).with_extremes(bad=...) (ornew_cmap(...).with_extremes(...) -- throughout this paragraph, read whatever spelling you prefer) is not that worse thanget_cmap(..., bad=...), and thatwith_extremes has the advantage of also working with non-builtin cmaps (and having the functionality both inget_cmap and inwith_extremes means having to duplicate the code and the docs, yada yada). Finally, having the parameters inget_cmap also modify a non-builtin-colormap passed as argument would be inconsistent with theN parameter ofget_cmap, which, for the better or (mostly?) the worst, does not resample non-builtin cmaps.

As you've pointed outget_cmap has quite some odd behavior. I think it should just return a registered colormap and that should be immutable. No passing through ofColormap inputs, no resampling etc. everything else should be done by creating new colormaps from existing colormap objects.

SinceColormaps are currently not immutable,get_cmap should return copies of the internal colormaps. It then makes sense to haveColormap.resampled() andColormap.with_extremes(). Maybe even better to have just one functionColormap.copy(N=None, bad=None, under=None, over=None) - naming is open for better suggestions.

Side remark: I'm also not sure if the segmentationN should be a is a fundamental aspect of all colormaps. E.g. one could imagine colormapping by functions. OTOH maybe there is just no need for this and you can always approximate the function onN segments.

I really like this pattern.

This does seem useful. Wasn't sure how it fit in w/@timhoffm plans for the colormap registry...

This does not interfere with my plans for the colormap registry (#18503). The registry only conerns registered colormaps. You can still have separate colormap objects and create new ones. In fact,with_extremes() would still be the canonical way to use custom extremes on a registered colormap, e.g. (API not finalized):

my_cmap = mpl.colormaps['jet'].with_extremes(...)