GeezerVison

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 clear technical 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 in Normalize with # docstring inherited

I want to point out that at the end of colors.py there is a private function _make_norm_from_scale() that defines a class Norm().
Do we care that we now have two classes named Norm in the context of this helper function, or should we rename this to NewNorm or NormFromScale etc.?

@functools.cache
def _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.
    """

    class Norm(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 named Norm, 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 to ScaleNorm or NormTemplate.

I changed it to ScaleNorm

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 of inverse() and all the non-invertable cases are explicitly checked before:

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

We could make the API for inverse() more explicit; i.e. make invertable optional and define errors if they are not. But since inverse() is only used in the above context, it may be better to not adopt inverse() in the base Norm 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 removed inverse() from Norm and moved the docstring from init 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.