Just for the record, I am still very hesitant on this idea, particularly because is it specific to colors, to the exclusion of any other property type. If this was generalized to be able to access one or more members from the cycler, I might warm up to the idea, but I still feel that this is wrong somehow.

Perhaps it would make more sense to allow some sort of interpolation feature into rcParams (a la configobject)? That way, users could define rcParam entries that are just simply list of values and they would also define the prop_cycle string using those entries. Then, they have complete access to the original list of values for use while also allowing prop_cycle to be dynamically defined in the rcParams. This also does not preclude my counter-proposal of attaching labels to iterations of the prop_cycler for reuse in subsequent plots. The currently proposed approach would make such a feature more difficult to implement in the future, I think.

Perhaps it would make more sense to allow some sort of interpolation feature into rcParams (a la configobject)? That way, users could define rcParam entries that are just simply list of values and they would also define the prop_cycle string using those entries. Then, they have complete access to the original list of values for use while also allowing prop_cycle to be dynamically defined in the rcParams.

I'm not opposed to that idea, but the point here is to have a super convenient syntax for accessing a color cycle. The use case is very common here, where people currently have a few things that are "grouped" that they want to plot all in the same color. Currently people tend to use the single character color names for this, but in doing so, they lose any advantage of having a nice set of colors that are specifically designed to have high contrast from each other, look good in print and screen etc.

plt.plot(x, y, 'b')
plt.scatter(x0, y0, s0, color='b')

We could also solve this by having some sort of grouping context:

with same_color():
   plt.plot(x, y)
   plt.scatter(x0, y0, s0)

but that is asking users to change their habits a lot and would be significantly more invasive to implement.

As nice as the cycler concept is, it does break down when trying to combine filled and unfilled things.

This also does not preclude my counter-proposal of attaching labels to iterations of the prop_cycler for reuse in subsequent plots.

I still like that suggestion in theory, but in practice it creates ambiguity about whether the user wants just the color or the whole set of styles from the current cycler "dictionary". I'd argue there's still a strong use for the former which this PR is trying to address.

I guess we need to figure out what to do with this one:

1. Include for 2.0
2. Postpone for post-2.0 when a better solution emerges

Either way we need to do something to address the problem we've created by making it harder to address the colors in the default color cycle.

Well, my vote is that this should be for 2.1 because it is a new feature. I also reject the notion that accessing the color cycle is any harder than it was before. Before, if one were doing that, they would have had to use rcParams['axes.color_cycle']. It is still possible to do that (albeit with a deprecation warning now).

What I am against is the assumption that color is the only thing that users will care about and the only thing that deserves a shortcut. This notation limits limits the possibilities for other properties, making any shorthand notations for them more difficult.

Perhaps it would make more sense to simply get rid of the deprecation warning?

Before, if one were doing that, they would have had to use rcParams['axes.color_cycle']. It is still possible to do that (albeit with a deprecation warning now).

I was thinking more that users used to use 'b', 'r' and 'g' etc., as many of our own examples do.

Note to self: This should also handle violinplot.

Replaced by #6291.