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 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.

You might be right that using _api.check_getitem is a good idea here, and it has been too long since I looked at this last.
I did some digging around, and this is what I found:

This is separated in a separate function because it is needed by both MultiNorm and Colorizer.
Initially, this PR was set to change Colorizer.norm(...) to use the new function, but I was asked to make the PR more readable by removing all changes not in MultiNorm proper.

In the Colorizer class (colorizer.py) we currently have:

    @norm.setter
    def norm(self, norm):
        _api.check_isinstance((colors.Norm, 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)()
        ...

Which I believe is syntax inherited from ScalarMappable.

Following your comment above, this could be changed to:

    @norm.setter
    def norm(self, norm):
        _api.check_isinstance((colors.Norm, str, None), norm=norm)
        if norm is None:
            norm = colors.Normalize()
        elif isinstance(norm, str):
            scale_cls = _api.check_getitem(scale._scale_mapping, norm=norm)
            norm = _auto_norm_from_scale(scale_cls)()
        ...

This will change the error of

plt.imshow(np.random.random((3,4)), norm='loG')

from
ValueError: Invalid norm str name; the following values are supported: linear, log, symlog, asinh, logit, function, functionlog
to
ValueError: 'loG' is not a valid value for norm. Did you mean one of ['log', 'logit']?
Which sounds like a good change to me, and does not cause any tests to fail on my machine.

With this context, I believe we should remove this function and either:
1.
Repeat the lines

            scale_cls = _api.check_getitem(scale._scale_mapping, norm=norm)
            norm = _auto_norm_from_scale(scale_cls)()

in both Colorizer and MultiNorm.

or
2.
Make a function

def _get_norm_cls_from_str(scale_as_str):
    scale_cls = _api.check_getitem(scale._scale_mapping, norm=scale_as_str)
    norm = colorizer._auto_norm_from_scale(scale_cls)()
    return norm

That perform both lines (rather than _get_scale_cls_from_str(...) which performed only the first).

I suggest we go with 1. for now, as it allows us to easily finish this PR.
I have therefore removed _get_scale_cls_from_str(...) from this PR.
I have not made any changes to Colorizer, as that can be done in a separate, independent PR.

Let me know if you agree @QuLogic