On 07/22/2013 10:42 AM, Nathaniel Smith wrote:
> On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom <md...@stsci.edu> wrote:
>> This is why I suggested that the best way forward is to implement some sort
>> of easy styling functionality (like what Tony Yu has submitted in #2236,
>> though I haven't had a chance to look at it yet), and make it explicit for
>> the user to select a new style. This could be either by adding a new line
>> to the top of the plotting script, or adding a single switch in the global
>> matplotlibrc file. But there needs to be an explicit turning on of this.
> Are you saying that the defaults can't change (i.e., any changes must
> be opt-in), or just that there needs to be some transition period
> before the defaults can change and a simple way to opt out afterwards?
> I agree with the latter :-).
I'm saying that there needs to be a transition period, and the start of
that transition would be to require an explicit opt-in of the new defaults.
>
> I have mixed feelings about a full "styling system" though, since, how
> many coherent "styles" for plots are there? If we provide a menu of
> plot styles right in the main documentation then it seems like it
> would just end up being an excuse for people to procrastinate playing
> with the different settings, and increase the number of manuscripts I
> read that have baroque and poorly chosen colormaps, plots that use the
> "ggplot as drawn by xkcd" style, etc. And what value would it really
> add? IMO we have a responsibility to nudge users towards making good
> plots, and that means having good defaults, and perhaps also means
> encouraging people to use them instead of just picking things that
> optimize some vague aesthetic judgement at 2am before the submission
> deadline...
>
> How about
> mpl.approximately_emulate(<version number>)
> which sets the defaults to whatever version of matplotlib is named?
> That could be used a-priori by people who want to future-proof their
> scripts, is very easy to add after the fact if you upgrade matplotlib
> and discover some plot of yours has been broken, and also encompasses
> the "future" functionality (you could ask your current matplotlib to
> emulate the next version, if it knows how).
>
> The advantage of a limited API that just takes a version number is not
> just that it's simpler on the backend (no need for a system to name
> and discover styles, etc. etc.), but it can also easily encapsulate
> knowledge like "the defaults were the same from 0.99 through 1.2, so
> if anything in that range is requested use *this* file, but then in
> 1.3...". This means that if a user knows that their plot worked on 1.1
> but broke on 1.4, they don't have to care -- they can just say
> mpl.approximately_emulate("1.1")
> instead of having to somehow figure out that the right call is:
> mpl.style("0.99-through-1.2")
>
I like this version idea. (Not sure about the name
"approximately_emulate", but that's a detail...) Other tools (sphinx,
for example) have a way of declaring what version was used when
something was created. If the user says:
matplotlib.styling_required('1.2')
then, if we're on 1.3, we do our best to load the styling defaults from
1.2, and display a warning to the effect "this plot was written for
matplotlib 1.2, we're running 1.3, so we're entering 1.2 compatibility
mode, but some things still may be broken. See the changes
documentation". (Again, we can work on the exact wording later).
I think this is a nice approach. I still think the ability to load
arbitrary styles from files, online etc. is required, though. There's
really two issues to resolve here: one is to make sharing of styles
easier (to have an institutional or publication style, for example), the
other is to transitition to better defaults with as little breakage and
pain as possible. I think we need to do both.
Mike
------------------------------------------------------------------------------
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
