You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a private method that validates color input. This method is designed for scaler key value pairs, for example _check_color_like(color='green', gapcolor='orange')
For each *key, value* pair in *kwargs*, check that *value* is color-like.
"""
fork, vinkwargs.items():
ifnotis_color_like(v):
raiseValueError(f"{v!r} is not a valid value for {k}")
I think this validation should be extended to list like input, something like _check_color_like(color=['green', 'orange', 'yellow']) or a second private function _check_color_like_listlike(**kwargs) that supports that input.
Proposed fix
The trickiest part of the coding is probably in sorting out how to recognize RGBA tuples as a color and not a list. And that might be partially solved by making a second function that always calls the list version -> this requires looking through the code for uses of color (hint: look for to_rgba) and checking if the type is ambiguous at the conversion stage. (For example in pie and bar, the colors could be either but are shoved into a generator and could be validated using _check_color_like as part of that loop iteration).
This was motivated by #24849 to be consistent with color checking in #23208
It's a good first issue because it's private API around printing a good error message and is not touching the public 'is_color_like' method. But, I will also accept if the solution is always use the singular case and wrap it in list comprehensions as needed.
The text was updated successfully, but these errors were encountered:
Please go for a separate explicit _check_color_like_list(**kwargs). This is an internal API and it's not worth the hassle distinguishing RGB(A) tuples from color lists.
Hey, I'm a first-time contributor and I took a try at making the _check_color_like_list(**kwargs) function in the PR above. It does not try to distinguish between RGB(A) tuples, however, it handles color list inputs correctly. Do you think my suggestion should be modified in any way? Thank you.
Uh oh!
There was an error while loading. Please reload this page.
Summary
There's a private method that validates color input. This method is designed for scaler key value pairs, for example
_check_color_like(color='green', gapcolor='orange')
matplotlib/lib/matplotlib/colors.py
Lines 237 to 243 in 651a874
I think this validation should be extended to list like input, something like
_check_color_like(color=['green', 'orange', 'yellow'])
or a second private function_check_color_like_listlike(**kwargs)
that supports that input.Proposed fix
The trickiest part of the coding is probably in sorting out how to recognize RGBA tuples as a color and not a list. And that might be partially solved by making a second function that always calls the list version -> this requires looking through the code for uses of color (hint: look for to_rgba) and checking if the type is ambiguous at the conversion stage. (For example in pie and bar, the colors could be either but are shoved into a generator and could be validated using
_check_color_like
as part of that loop iteration).This was motivated by #24849 to be consistent with color checking in #23208
It's a good first issue because it's private API around printing a good error message and is not touching the public 'is_color_like' method. But, I will also accept if the solution is always use the singular case and wrap it in list comprehensions as needed.
The text was updated successfully, but these errors were encountered: