Closed domoritz closed 10 years ago
Just noticed this myself. The colors show up in the correct way like the documentation examples when using prettyplotlib=0.1.3.
If you don't pass an Axes
object as the first parameter, the colors do work. For example, this will give the expected easy-on-the-eyes colors:
ppl.plot(np.random.normal(size=1000).cumsum())
ppl.plot(np.random.normal(size=1000).cumsum())
ppl.plot(np.random.normal(size=1000).cumsum())
The problem is the new version of ppl uses the @pretty
decorator to invoke matplotlib's rc_context
context manager to set the colors used in each plotting function. However, if you pass an Axes
object to the plotting function, it will have been created under a different context and won't pick up the right rc_params
.
I'm not sure if it is possible to use the rc_context
approach and still allow passing in an Axes
object.
I see what you mean. This seems to suggest that utilizing the colors with ppl in subplots isn't an option.
A possibilty would be to add a ppl.prettify
function which could be called on an Axes instance to reset its parameters, as if it had been created under the prettyplotlib context. Probably with a big fat warning, "no guarantee on results if the axes instance has already been drawn onto".
Another possibility, which I prefer now, would be to turn ppl.pretty
into a ContextDecorator (https://docs.python.org/3/library/contextlib.html#contextlib.ContextDecorator) and require the user to enter the pretty
context before instantiating any Axes that are supposed to use ppl colors.
It looks like with matplotlib 1.3.1 plotting doesn't pick up the right colors.
numpy==1.7.1 prettyplotlib==0.1.7 brewer2mpl==1.4 matplotlib==1.3.1
I'm looking at the example from https://github.com/olgabot/prettyplotlib/wiki/Examples-with-code#plot-lines-eg-time-series-with-a-legend
Creates the following image: