'image.cmap' -- nice! Shows how much I know :)
I don't fully agree with Eric that changing the defaults should be treated
as an API break -- yes, it may irritate a minority of users, but their code
will still run. I'd flip around your argument for the role of rcParams and
customization: the majority user is probably someone who doesn't know much
about rcParams, or all the ways plots can be customized. *That* is the use
case to optimize, not the "legacy" users invested in the current style.
However, default tweaking need not be painful. As has been mentioned, a
first step would be an easier way to change a whole set of rcParams:
something like mpl.set_style('style-name'). As long as one style is
'classic', users can keep the current style for as long as they want. It's
a one line fix, and could even be rcParams-settable.
With such a framework, it would be possible for people to contribute new
styles that ship with MPL, and users could change styles without having to
find (and potentially merge) rcParams files from the web. Finally, people
could nominate that mature styles be made default (you could even assign
version numbers to track the default style as it evolves towards visual
awesomeness)
chris
On Sat, Jul 20, 2013 at 9:07 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 2013/07/20 2:38 PM, David P. Sanders wrote:
> > And this is my problem with 'rc': it brings to mind an arcane config
> > file hidden away somewhere that has a terrible syntax and must not be
> > touched.
> >
> > As Chris and Adrian have emphasized, the point is that we *should* be
> > tweaking away at the parameters all the time.
> > I propose to rename as mpl_params=rcParams
> >
>
> Yes, mpl_params is more descriptive and easy to remember. rcParams is
> ugly, obscure, and archaic. It will have to remain available for a long
> time, but I don't object to changing standard usage to a nicer name.
> There might even be a better name than "mpl_params"--"settings" comes to
> mind, or maybe "style".
>
> As for parameter tweaking: the defaults shipped with mpl should be
> changed only rarely, but we should make it as easy as possible for users
> to customize plots, including coming up with good combinations of style
> parameters. In some cases it makes sense to do this via a matplotlibrc
> file, in other cases it is better to do the parameter setting explicitly
> at the top of a script.
>
> Regarding defaults, note that I said "rarely", not "never".
>
> The whole rc system could use a good review--maybe resulting in lots of
> changes, maybe not--so I welcome the attention you are directing to it.
>
> Eric
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
