Tony S Yu wrote:
On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote:
Tony S Yu wrote:
Hey Dominik,

I'd also like to see the default color_cycle be customizeable. But, if
I'm not mistaken, this approach doesn't quite do what you want (at least
it doesn't on a recent version of mpl). The problem is that the color
given by lines.color (rcParam) sort of overrides the first color in the
specified color cycle (see
``_process_plot_var_args._clear_color_cycle`` in

It seems important for lines.color and the first color in the color
cycle to match since this matching is also enforced in
``axes.set_default_color_cycle``, except in reverse (the first color in
the color cycle overrides line.color). If both lines.color and
axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
be issues with how to match the two (e.g. which takes precedence if they

As I said earlier, I'd like to see this change made, but I think it may
change the current behavior. Maybe a mpl developer could weigh in?

Hi Tony,
You are correct, line color overrides the first cycle color. That does
not appear a very happy choice to me but this way or another you can
still specify BOTH lines.color and the cycle in the param file to get
whatever you want, no?


Yup, that should do exactly what you want. But, since it's a bit of a hack (you should only need to make 1 change to matplotlibrc), I doubt this patch would be appropriate for the main distribution.

Ideally, we'd need to figure out if the matplotlibrc changes 1) only lines.color and make this the first color in color_cycle, 2) only lines.color_cycle and make the first color override lines.color, or 3) both lines.color and lines.color_cycle (behavior unknown if colors don't match). Unfortunately, I don't see an easy way to tell if rcParams have been changed from their default values.

Hi Tony,
My patches (there were two!) remove the badly hardcoded definition of
defaultColors in and instead define default axes.color_cycle in (defaulting it to the already established color array
['b','g','r','c','m','y','k']). Now, in, defaultColors are taken
from rcParams, and not a hardcoded array, so unless you modify your own
rc file, you will get the old behavior. It is if and only if you define
your color_cycle in your own rc file that will do anything new. I do not
see how this introduces any incompatibilities.

Sorry for the confusion. I wasn't saying your patches introduce incompatibilities, but I did say that their behavior is not ideal. For example, your matplotlibrc requires *both* "lines.color_cycle : w, w, w, w, w, w" (actually I think you only need one "w,") *and* "lines.color : w". Ideally (at least IMO), I should only need to set the color cycle, and it was surprising to me (surprises = bad) that I'd have to also set "lines.color"

The incompatibilities I spoke of would only be true if you went with my suggestion to deprecate "lines.color".