On Thu, Jan 5, 2012 at 6:45 AM, Michael Droettboom <md...@stsci.edu> wrote:
> This is great! Absolutely a much-needed and much-requested feature.
>
> I wonder, however, about the need for function-specific color cycles. Is
> there a use case there? I'd be just as happy with a single global color
> cycle that all functions would use.
>
>
There are two reasons I see for this. First, maintaining current
behavior. For example, pyplot currently uses the same color regardless of
the number of times a user calls scatter. That might be a feature for
some, or at least, it would be undesired to change that for existing code.
I don't know how strong this argument is, but I did not want to
unilaterally make this change.
Second, and possibly more strongly is the following two use-cases:
for y1, y2 in zip(linedata, bardata) :
plt.plot(x, y1)
plt.bar(x, y2)
and
for y in linedata :
plt.plot(x, y)
for y in bardata :
plt.bar(x, y)
I would assume that in these cases, the user would expect that the line
plot using y1 would have the same color as the bars using y2. Also, that
the two figures would be identical. Implementation-wise, if there is a
single color cycle object for these functions to draw from, then this can
not be guaranteed without internally creating a per-function color-cycle
objects. Once you are at that point, then it is only a short jump to just
allowing users to specify per-function color-cycles anyway.
I also like the suggestion of a "style" class that would store a bunch of
> drawing attributes on a single object.
>
At the very least, it would help in compartmentallizing all the possible
drawing attributes that are common across all artists. Currently, I am
envisioning using a defaultdict object (which was introduced in python 2.5)
or subclassing from it. This might help in keeping compatibility with
existing code. Subclassing would allow for modifying __get__ and __set__
to treat some elements like 'c' and 'color', 'lw' and 'linewidth' and so on
as the same.
>
> From that, a feature that might be nice would be the ability to pass
> "style='last'" (or something) to a plotting function and have it use the
> last style in the cycle again. This would allow one to draw (for example)
> a line and a bar plot that are related in the same color, and then draw
> another line and bar pair in a different color. But that's icing on top of
> the more important features you've already proposed.
>
Hmmm, this could possibly be a solution to avoid the problem I mention
above. So, in the pyplot state-machine, there would not only be the cycle
objects, but also a current style state that would not trigger a next()
call on the cycles if the plotting function states that it wants the
current style. Interesting...
Ben Root
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
