After discussion on this weeks call I think we should go with the ABC flavor. Given:

• from a technical point of view both do the job and there is no cleartechnical winner so it is subjective call
• @timhoffm prefers ABCs
• some of our core developers learned Protocols exist due to this discussion
• ABCs have been around a lot longer than Protocols
• we don't have any Protocols currently in the code base

If we are going to bring in a new language feature we should do that when it brings in a clear benefit so we should stick with ABC.

The docs failure is real, The new class needs to be manually added to the rst.

If I'm not mistaken, once you put the base class into Sphinx, you can replace the duplicate docstrings in the no-longer-base class with# docstring inherited.

The doc build failure looks a bit cryptic, but I think putting Norm here will solve it
https://github.com/matplotlib/matplotlib/blob/main/doc/api/colors_api.rst#color-norms

Thank you@tacaswell@timhoffm@QuLogic
The docs should be fixed now, and I replaced the docstrings of the methods inNormalize with# docstring inherited

I want to point out that at the end ofcolors.py there is a private function_make_norm_from_scale() that defines a classNorm().
Do we care that we now have two classes namedNorm in the context of this helper function, or should we rename this toNewNorm orNormFromScale etc.?

@functools.cachedef_make_norm_from_scale(scale_cls,scale_args,scale_kwargs_items,base_norm_cls,bound_init_signature,):"""    Helper for `make_norm_from_scale`.    This function is split out to enable caching (in particular so that    different unpickles reuse the same class).  In order to do so,    - ``functools.partial`` *scale_cls* is expanded into ``func, args, kwargs``      to allow memoizing returned norms (partial instances always compare      unequal, but we can check identity based on ``func, args, kwargs``;    - *init* is replaced by *init_signature*, as signatures are picklable,      unlike to arbitrary lambdas.    """classNorm(base_norm_cls):def__reduce__(self):cls=type(self)# If the class is toplevel-accessible, it is possible to directly# pickle it "by name".  This is required to support norm classes# defined at a module's toplevel, as the inner base_norm_cls is# otherwise unpicklable (as it gets shadowed by the generated norm# class).  If either import or attribute access fails, fall back to# the general path.

It doesn't create a class namedNorm, but<Scale>Norm. I suppose we should rename the temporary to reduce confusion, but it's not required from a technical point-of-view.

Let's rename it toScaleNorm orNormTemplate.

I changed it toScaleNorm

I think this PR is ready to be merged now :)

EDIT: I spoke before the tests had completed
EDIT 2: I am not able to relate the test that fails on macos-13/python 3.11 to any changes in this PR.
FAILED lib/matplotlib/tests/test_backends_interactive.py::test_blitting_events[MPLBACKEND=macosx-BACKEND_DEPS=matplotlib.backends._macosx] - assert 0 < 0

Are all norms invertible?

BoundaryNorm isn't (or is only invertible up to bin edges).

Actually, all norms are not invertible until they are scaled

(or if vmin=vmax).

There's only one usage ofinverse() and all the non-invertable cases are explicitly checked before:

In fact, the whole song and dance is only done to getdelta / the number of significant digits.

We could make the API forinverse() more explicit; i.e. make invertable optional and define errors if they are not. But sinceinverse() is only used in the above context, it may be better to not adoptinverse() in the baseNorm at all. Instead, let the norms provide the relevant information (delta / the number of significant digits). This also removes all the special checking in the code block above.

I removedinverse() fromNorm and moved the docstring frominit to the class :)

I think it would be good to merge this now, so I can go back to working on#29876

Merging as is. We can improve on the inverse handling separately.