😨

I've removed "Good first issue", because IMHO resolving this is not easy:

1. Find out if this has always been the case or if it is a regression.
2. Decide how to procede: fix / deprecate / document (should probably discussed in the dev call)
3. If document I think very good wording is essential so that we communicate clearly but at the same time do not appear too weird or dumb.

The issue seems to be that the long names are CSS4 colors, which do not match the base (original MATLAB?) colors for c,m, y.

The values of {'c', 'y', 'm', 'g'} have been what they are from at least e34a333 (2004). I have a vague recollection of discussing changing this around the 2.0 style changes. Given that we were committed to providing an easy way to get back to the old style, if we changed the meaning of 'b' we would have to add an API (even if only private) to control the str -> rgb mapping which seemed a bridge too far.

The single-letter colors are defined at

While walking through the blame on this I found that in 2016 I tried to change the single-letter names to be hex like the rest of the color definitions and that broke tests so got abandoned.

From my attempts to look at the MATLAB docs (which I can only find back to 2015 online) I don't think this is something we inherited from them. I suspect that this "dimming" of the colors was an intentional aesthetic choice, but we would need confirmation from someone who was around back then.

This decision predates me, I'm afraid (though I remember the discussion in the 2.0 timeframe of how to handle this in a backward compatible way, if at all). Maybe @efiring knows?

I think we did inherit the single-letter colors from Matlab. I suspect JDH did this in the very beginning. In early days of both Matlab and mpl, they were the most commonly used colors, by far, forming the default color cycle. There was never any intention that they correspond to colors from some extensive set; they are obviously very simple modifications of RGBCMYK extremes. The modifications are to make them work better. The clearest example of this 'y'. It is much more visible than "yellow". As a color for a line, "yellow" is unusable.

Wherever the docs has "one of {'b', 'g', 'r', 'c', 'm', 'y', 'k', 'w'}, they are the single character short-hand notations for blue, green, red, cyan, magenta, yellow, black, and white." it could be modified, "...notations for shades of blue...and white, respectively. The particular shades were chosen early in the development of Matplotlib to be suitable for lines against typical backgrounds." The hope here is that the "shades of" phrasing would help reduce any expectation that 'y' should be the same as "yellow". This expectation should already be somewhat reduced by the current phrasing, in which 'y' is in quotes but yellow is not. The former is a name, the latter is generic.

I just remembered there are multiple locations of this, and #17665 only updated one of them. There's also:

• module docstring of lib/matplotlib/colors.py
• example examples/color/color_demo.py (though it doesn't say what the single-character colors mean, so maybe that's fine.)

A suggestion might be to have long names for these shades so they aren’t ambiguous. Ie mpl-yellow ?

I don't think we need yet another set of names. The single-letter characters won't go away by introducing corresponding long names. They don't get less ambigous as well: You could only make the connection 'y' -> 'mpl-yellow' in the docs, but that's not better than directly explaining 'y' is a shade of yellow, in fact you still would have to do that.