Re: [matplotlib-devel] Release schedule for version 1.0.1?

[James E. <jre...@ea...>]

In reference to the configuration package idea...

I (and the users that I support) use matplotlib both as a standalone plotter
for generating lots of plots, as an interactive plotter, and as an embedded
plot in an application environment.  In all of these instances we have found
the '.matplotlibrc' mechanism to be severely lacking in control of plot
formats.  Users will be generating series of plots that are going to be
embedded into documents and therefore want a uniform look and feel to those
plots.  Later they want to generate some plots for use on an overhead
projector (which has a much different DPI).  Another time they are
interactively plotting on their workstation and still again doing all this
in an embedded form as well.

The solution we have come up with, although a little bit of a hack, is a
configuration/formatter class, where instances are used to manage the
formatting of the plots.  Each instance can represent a specific set of
configurations controlling everything from font properties to background
color.

The difference here is that having global defaults is all fine and dandy,
but sometimes just setting a global default is not enough and controlling
the setting as an encapsulated entity that can be passed around and selected
at will can be quite useful.

Just my $0.02

--James Evans


> On 10/28/10 12:46 PM, Russell E. Owen wrote:
> 
> > It's an interesting question. You can't call a matplotlib function to
> do
> > it because it has to happen before matplotlib is loaded. I suppose
> there
> > could be a configuration package to perform the operation.
> 
> I actually like that idea. It could even do a bit more, like have the
> matplotlib.use() function, and who knows how many others.
> 
> I've never liked the .matplotlibrc approach -- it makes great sense for
> an interactive environment, but not so much for embedding MPL in other
> apps, for all the reason's Russell has laid out.
> 
> If there was a mplconfig module that you could import first, and have
> functions in there where you could set all the defaults the way tyou
> like them, it would be easier to make self-contained MPL apps that
> didn't step on each-others toes.