Re: [Matplotlib-users] cycling mechanism

[Ryan M. <rm...@gm...>]

On Jan 4, 2012, at 20:52, Benjamin Root <ben...@ou...> wrote:

> Hello all,
> 
> So, I am getting to the point where I need to implement a color cycling mechanism throughout pyplot.  So, before I get too deep in implementing it, I have some thoughts that I need feedback on.
> 
> 1) Not all plotting functions use color cycling right now.  Currently, only plot() and any function that calls plot in its process (such as errorbar()). Glaring omissions are bar() and scatter(), and pie() could also benefit from having a uniform cycling mechanism. So, the issue going forward is, do we want to enable common cycling for all the pyplot/axes plotting functions which would require updating the test images and break backwards compatibility (in a sense), or do we want to have a per-function default rcparams that would contain one-element cycles that would effectively maintain current drawing results?
> 
> 2) I also have the need to implement line-style cycling for b&w publications. Of course if I implement that, then why not hatch-cycling? marker-cycling? I have seen use-cases for all of these, and I am considering how to have a generalized framework for this. So my question is, what attributes would we like to see cycle-able? Here is a short list and some usecases I have come up with.  Please extend this with ideas of your own.
> 
> color - plot(), errorbar(), scatter(), bar(), hist(), pie(), stem()
> linestyle - plot(), errorbar(), stem()
> hatch - bar(), hist(), pie()
> marker - plot(), errorbar(), scatter(), stem()
> 
> linewidth? facecolor/edgecolor? joinstyle?
> 
> 3) rcparam names.  I was thinking about how to name these cycles in the matplotlibrc file.  Possibly:
> 
> cycle.colors
> cycle.linestyles
> cycle.hatches
> cycle.markers
> 
> And these would represent the global default, meanwhile, function-specific cycles could be given by:
> 
> cycle.colors.pie
> cycle.colors.bar
> cycle.linestyles.plot
> cycle.linestyles.errorbar
> 
> I was thinking that in code, one would access the full name attribute for the function, and I would extend the __get__ function to intelligently fall back to the global default if the full-name attribute is not specified. However, would there be confusion in a situation such as a person who wanted to use barh() but only had specified cycle.colors.bar?
> 
> 4) Ultimately, my goal is to be able to create some typical profiles that have useful cycle specs, and possibly make some available as convenience functions, such as a b&w mode. Such a mode would set the default colormap to a grayscale-friendly colorscale, and use line style, hatch and marker cycles instead of a full color cycle.
> 
> Thoughts? Comments?

My first thought is that maybe we need an object to collect and abstract all of these style attributes, and then cycle through a sequence of those. In the future we could move the matplotlib API to use such an object instead of the billion parameters that are individually passed now.

Just 0.02 to distract me from the dissertation.

Ryan