I guess this seems overkill to me, and fragile as shown by the pickling issue? Why don't we just usescale._scale_mapping or make one, i.e.colors._norm_mapping? Do we really need the extra flexibility given by allowing dynamic creation?

I don't really want to create a separate mapping as people can register new scales (e.g. mpl-probscale does it), but they wouldn't show up in the norm mapping if these are separate.

Back when I was a whippersnapper, we only had the linear norm and we liked it....

I'm not sure that making this super-flexible is worth the complication. The strings can be for a few common norms. How many specialized scales truly need a norm as well, and how much of a problem is it to ask users to just pass the norm instead to the string? Its not like probscale is going to be a super-useful color norm. If you wanted to add aregister_norm, fine, but making it all dynamic just seems to be asking for trouble.

#20755 fixes that part.

There should only be one space after a period for most (all now?) style guides, so this shouldn't be updated. Same for the other docstrings in this PR.

I'm wondering if it would be helpful to wrap this in a try-except and re-raise with a list of options available for users?

I can see users trying:imshow(..., norm="Boundary") and wondering what option would work instead.

Overall I think this is a great idea. However, all the scales with strings currently have Norm classes, don't they? If so, why are you creating a new class here versus using the existing classes? It seems like it will just make things needlessly confusing.

1. Some scales (most prominently, logit) don't have a norm associated;
2. because everything is wrapped under lru_caches,_auto_norm_from_scale(LogScale) is going to be exactly the same object asLogNorm (multiple calls tomake_norm_from_scale or_auto_norm_from_scale always return the same norm class). (I added a test for that.)

Can you document that here? Because I couldn't parse that from the code, but maybe my ignorance of how the caches get shared across submodules.

However, I'm still not understanding what happens if the user puts 'logit' in here. Are you saying a norm will still be created?

The documentation is the third bullet point below ("The returned norm class is memoized and reused for later calls." But feel free to suggest something clearer). Yes, a norm class will be dynamically created if the user puts in "logit" (and later calls will reuse the same dynamically created norm class).
This will also work with scales provided by third-parties, e.g. mpl-probscale (which is why I did not go for just an explicit and exhaustive mapping of names to norm classes -- this would not work with third-party scales).

this would not work with third-party scale

Fair enough if we are supporting those as norms, though that sounds risky to me...

The returned norm class is memoized and reused for later calls.

Maybe just a bit more verbose "the returned norm class is the same as for make_norm_from_scale (so norm='log' will return a LogNorm instance); these are are also memoized..." (though is there a reason to not use "cached"? "memoized" is pretty jargon, but maybe my ignorance)

Re: 3rd-parties: well, that was also one of the points of the PR (and again, think of this as "supporting putting a third-party scale on a colorbar axis").
Re: docs: sure, reworded, sorry for the jargon :)

Edit: actually I had to fix the caching, but it should be good now.

I had a bit of confusion initially figuring out exactly what is being cached. The cached "thing" is the class definition. It is not the returned Norm object. So, these two calls will have different LogNormalize objects, which is consistent with how it works currently when no norm is given (a new Normalize object is created each time).

im1=ax.imshow([[0,1]],norm="log")im2=ax.imshow([[0,1]],norm="log")assertim1.normisnotim2.norm

Good point, I further reworded the docs to clarify that.

I'm not really sure about this wording? (Why "by default"? 1) I guess youcould change that, but having a linear-scale colorbar for a lognorm seems rare; 2) more than anything, this kwarg sets the norm on the mappable; setting the colorbar scale is more a side effect of that. Also, even set_xscale doesn't mentionget_scale_names. Perhaps it should, but if it doesn't, I don't think imshow() needs to do that either.)

"one of "linear", "log", "symlog", "logit", etc." is vague, so was trying to be more precise. "...as if using the scale" was also theoretical sounding, whereas wedo use the scale for the colorbar, so why not be explicit? As for "by default" - the user can change the colorbar scale. But I don't feel strongly about my wording - feel free to iterate as you see fit.

I guess this needs to all be copied over.

Given#20753, I made this case-sensitive from the beginning.

IMHO it's a bit easier to read this way.

I think not all functions using cmap support RGB(A) data. Now that we have entries per parameter it is possible to do move this out of the general description and do

%(cmap_doc)s        This parameter is ignored for RGB(A) data.

only when needed (or make acmap_rgba_doc if there are many cases).

Actually, none of cmap, vmin/vmax, and norm apply for RGBA data, so all of them should get this comment.

Um, that's not what I meant. We have functions likescatter that allow either colormapped or RGBA data. Here, the sentence makes sense. But we also have functions likehexbin, that only operate with colormapping. Mentioning that a parameter is ignored for RGBA data when RGBA data is not supported by the function is somewhat confusing.

Sorry I was unclear, I was meaning "all of cmap, norm, and vmin/vmax should get this comment". From a quick check, the only functions that do not take color input are hexbin and hist2d; do you agree?

From a quick search, I think the following functions support color input:

• scatter
• hexbin
• imshow
• pcolor
• pcolormesh
• pcolorfast
• hist2d
• specgram
• contour
• tripcolor

Feel free to update the list.

Even if it's only hexbin and hist2d, how do we handle them?

OK, this should be handled now.