Currently, it can take multiple lists of colors as inputs,

I think it's good for it to match the color like API and I really really like that you collect the wrong colors and print them as a list rather than failing at first invalid. I think that can save so much headache down the line.

It seems you can actually convert "none" to a colour:

>>> from matplotlib import colors
>>> colors.to_rgba("none")
(0.0, 0.0, 0.0, 0.0)

so I think you just need to pick a different bad colour for your tests.

At this point, I'm not sure what's causing the test to keep failing, I assume there's something about re-escaping in regex that I don't understand.

E AssertionError: Regex pattern did not match.
E Regex: "['abcd'] are not valid value(s) for c"
E Input: "['abcd'] are not valid value(s) for c"
E Did you mean to re.escape() the regex?

Could be wrong, but I wonder if it's like #24403 and you need a similar escape type thing, something like r"\['abcd'\] are not valid value(s) for c"

ETA: I tried this on my machine and I think it worked

Is there a place to add this and use it to the codebase as well? I worry that we are adding a private method that is never used and then someone will come and clean it up if there is no use case for this in the current code.

I wanted it for #24849, which hasn't gone in (yet) but likely there are other places.

I agree with @greglucas I think this should go in where it is used. I'm not understanding the need for this in the abstract.

Note that we do not typically test private methods.

Sorry this had a lot of back and forth - but I'm not particularly in favour of this going in with no application.

I spun this off into its own issue so that I wouldn't suggest @rcomer implement this as part of her PR. The specific use case is parity with the gap color implementation that uses the singular case.

Edit: while we don't typically test private methods, I don't think it hurts to validate that a validation function isn't broken.

For setting colours on collections, we use to_rgba_array. This function currently throws a good exception if you pass a single wrong colour:

In [1]: from matplotlib.colors import to_rgba_array

In [2]: to_rgba_array("octarine")
---------------------------------------------------------------------------
<snip>

ValueError: 'octarine' is not a valid color value.

For a list of colours, I agree it could be more helpful:

In [3]: to_rgba_array(["skybluepink", "octarine"])
---------------------------------------------------------------------------
<snip>

ValueError: Invalid RGBA argument: 'skybluepink'

So I would be inclined to use this new helper within to_rgba_array, so that all the various colour setters automatically get the benefit.

Somewhat in agreement with various comments above, I think that this should not exist as an independent function at all, and to_rgba_array already provides the desired functionality. (Alternatively, consistently with is_color_like, we could have is_colors_like (plural) returning True/False, but I think the point here is more about the error message?)

We could consider making to_rgba_array emit an error message with all the incorrect values, but I'm also quite opposed to that, because that list could be arbitrarily long and there isn't much of a point in spamming the user with hundreds of invalid values. Again this is consistent with CPython itself, see similar discussion at #24889.

I'm also quite opposed to that, because that list could be arbitrarily long and there isn't much of a point in spamming the user with hundreds of invalid values.

I think flagging once "hey check all your input" is more user friendly than a script that can take however long erroring out however many times it takes for the user to figure out that they've got hundreds of invalid values.

Also 'to_rgba' doesn't say which kwarg argument this was passed in through and I think that's really useful for the tracing.

I think flagging once "hey check all your input" is more user friendly

The error message could easily be something like "At least one invalid RGBA argument: ..." or "Invalid RGBA argument: ... (further values may be invalid too)".

'to_rgba' doesn't say which kwarg argument this was passed in through

I would grow the signature to to_rgba_array(..., errname=...) (name up to bikeshedding) if you want to customize that.

I would grow the signature to to_rgba_array(..., errname=...) (name up to bikeshedding) if you want to customize that.

I like this suggestion but at that point does it make sense to also replace _check_color_like since I think almost everything hits to_rgba or to_rgba_array anyway?

basically my initial motivation was to have a consistent validation path for colors and arrays of colors - I'm not overly particular about whether the recommended path is always convert to RGBA or pass through via _check_color* and then convert...

If this is too much for @i-deal then I can open a new PR w/ i-deal as a co-author (or maybe make changes on this branch but the GitHub app doesn't tell me what branch this was made on)

I wouldn't mind killing _check_color_like too.

Hey @i-deal, sorry but consensus is that this isn't gonna go in because folks are happy with to_rgba_array and do not want to add a second validation method. Thank you so much for your work here and sparking a discussion on validation consistency. I'm gonna open up a follow up PR removing _check_color_like and replacing it with to_rgba because I think there will be some discussion of growing the signature and how to do the drop/whether to do a drop in in that I'm concerned may be a little too much for a new contributor to manage, but I will credit you as a coauthor. Thanks again!

ETA: the replacement pr is #25140 and @i-deal please take a look/leave comments/reviews/suggestions.