I'm confused because this function is only called for isinstance(norm, str).

So this function exists because the norm keyword accepts Normalize objects in addition to strings.
This is fundamentally the same error you get if you give an invalid norm to a Colorizer object.

In main, the @norm.setter on colorizer.Colorizer reads:

    @norm.setter
    def norm(self, norm):
        _api.check_isinstance((colors.Normalize, str, None), norm=norm)
        if norm is None:
            norm = colors.Normalize()
        elif isinstance(norm, str):
            try:
                scale_cls = scale._scale_mapping[norm]
            except KeyError:
                raise ValueError(
                    "Invalid norm str name; the following values are "
                    f"supported: {', '.join(scale._scale_mapping)}"
                ) from None
            norm = _auto_norm_from_scale(scale_cls)()
    ...

The _get_scale_cls_from_str() exists in this PR because this functionality is now needed by both colorizer.Colorizer.norm() and colors.MultiNorm.
Note this PR does not include changes to colorizer.Colorizer.norm() so that it makes use of _get_scale_cls_from_str(). These changes follow in the next PR: #29877 .

I understand 0, but is there a reason we can't gracefully degrade to 1D-Normalize behaviour if passed only 1?

I'm thinking of someone doing MultiNorm(norms) where norms is some dynamically deduced thing, and having to special-case 1 seems annoying.

@timhoffm Do you agree with @QuLogic that we should allow a single norm?
I'm fine with it either way

I don't see a practical use case for 1-element. This "dynamically deducing" seems a bit unlikely. But OTOH there's also no benefit in reqiring at least 2. So a list of length 1 is ok to accept.

Use np.broadcast_to as well?

Is this really supposed to be a tuple of a single float? Or a single float (float)? Or a tuple of floats (tuple[float, ...])?

should be tuple of floats, I'll fix it. Thanks for spotting it

Is this unused?

Maybe use _api.check_getitem which automatically chooses the right keys,

should work.

There used to be a comment stating why api.check_getiem is not used here, but not sure where it went.

In any case, the reason is that the error message produced by api.check_getitem indicates that only stings are valid for the norm keyword (I.e in imshow). In reality, both strings and Normalize objects are valid, which is why the error message here specifies «invalid norm name»

But check_getitem doesn't say anything about strings, just the keys from the mapping you give it, and this current exception here doesn't say anything about Normalize objects either, just the keys from the mapping.

It's always good to show the offending value for context

Also in all similar error messages