Plot or Not: voting to create better matplotlibrc

Hi,

Probably many of you know about “Plot or Not”, a site where we vote on the same plot presented in different ways, to get feedback about better matplotlibrc params:

http://warm-escarpment-9042.herokuapp.com/

It seems to me an absolutely fantastic idea! I think many people do not realise how fantastic the plots can look with some of this modern styling. (Styling was mentioned several times at SciPy.)

Would it be possible to put a link to this site on the matplotlib web page and encourage people to use it?

Definitely time to update the defaults!!

Best wishes,

David.

···


Dr. David P. Sanders

Profesor Titular “A” / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)

dpsanders@…552…1147…
http://sistemas.fciencias.unam.mx/~dsanders

Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

Hi,

Probably many of you know about "Plot or Not", a site where we vote on
the same plot presented in different ways, to get feedback about better
matplotlibrc params:

http://warm-escarpment-9042.herokuapp.com/

It seems to me an absolutely fantastic idea! I think many people do not
realise how fantastic the plots can look with some of this modern
styling. (Styling was mentioned several times at SciPy.)

Would it be possible to put a link to this site on the matplotlib web
page and encourage people to use it?

David,

Interesting, but I'm not sure this is a good approach. I really don't see the point of the voting. What I think would be more useful would be a set of matplotlibrc files with examples of their effect on at least a few plot types.

Definitely time to update the defaults!!

Or maybe include a representative set of rcParams combinations to make it easier for people to choose a design that suits their purpose. This could be part of a toolkit.

Eric

···

On 2013/07/20 4:18 AM, David P. Sanders wrote:

Best wishes,
David.

--
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de F�sica, Facultad de Ciencias
Universidad Nacional Aut�noma de M�xico (UNAM)

dpsanders@…1147… <mailto:dpsanders@…1147…>
http://sistemas.fciencias.unam.mx/~dsanders
<http://sistemas.fciencias.unam.mx/~dsanders>

Cub�culo / office: #414, 4o. piso del Depto. de F�sica
Tel.: +52 55 5622 4965

------------------------------------------------------------------------------
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

From discussions with others at SciPy, we found ourselves disagreeing on what default we would want. We also weren’t sure exactly which params were the ones that people tended to change. We have zero data on this. This site is intended to help start that data collection process.

We can certainly improve this site to collect other kinds of info, but this is just a start. One could also view this as a launching point for teaching how to use rcParams (sorry David, i kinda like that name) in mpl. You all know I never let a good teaching moment go to waste!

As for linking from matplotlib.org, I am ambivalent. It is a bit gimmicky, and I do worry about being counterproductive to efforts in SciPy to be more inclusive of women (given the rather anti-feministic undertones of the site we are parodying). Of course, that could just be me being overly cautious.

Cheers!
Ben Root

···

On Jul 20, 2013 2:20 PM, “Eric Firing” <efiring@…229…> wrote:

On 2013/07/20 4:18 AM, David P. Sanders wrote:

Hi,

Probably many of you know about “Plot or Not”, a site where we vote on

the same plot presented in different ways, to get feedback about better

matplotlibrc params:

http://warm-escarpment-9042.herokuapp.com/

It seems to me an absolutely fantastic idea! I think many people do not

realise how fantastic the plots can look with some of this modern

styling. (Styling was mentioned several times at SciPy.)

Would it be possible to put a link to this site on the matplotlib web

page and encourage people to use it?

David,

Interesting, but I’m not sure this is a good approach. I really don’t

see the point of the voting. What I think would be more useful would be

a set of matplotlibrc files with examples of their effect on at least a

few plot types.

Definitely time to update the defaults!!

Or maybe include a representative set of rcParams combinations to make

it easier for people to choose a design that suits their purpose. This

could be part of a toolkit.

Eric

Best wishes,

David.

Dr. David P. Sanders

Profesor Titular “A” / Associate Professor

Departamento de Física, Facultad de Ciencias

Universidad Nacional Autónoma de México (UNAM)

dpsanders@…1147… mailto:dpsanders@...1147...

http://sistemas.fciencias.unam.mx/~dsanders

<http://sistemas.fciencias.unam.mx/%7Edsanders>

Cubículo / office: #414, 4o. piso del Depto. de Física

Tel.: +52 55 5622 4965


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


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

From discussions with others at SciPy, we found ourselves disagreeing
on what default we would want. We also weren't sure exactly which params
were the ones that people tended to change. We have zero data on this.
This site is intended to help start that data collection process.

Then it might help to add some introductory info to the page. When I went to it, all I saw was two versions of a plot and 3 buttons. That was not enough to motivate me to go further, so I don't know what would have happened if I had clicked one of the buttons.

We can certainly improve this site to collect other kinds of info, but
this is just a start. One could also view this as a launching point for
teaching how to use rcParams (sorry David, i kinda like that name) in
mpl. You all know I never let a good teaching moment go to waste!

Maybe the teaching would happen after clicking one of the buttons; it certainly was not apparent to me from the first page that there was a prospect of learning something.

As for linking from matplotlib.org <http://matplotlib.org>, I am
ambivalent. It is a bit gimmicky, and I do worry about being
counterproductive to efforts in SciPy to be more inclusive of women
(given the rather anti-feministic undertones of the site we are
parodying). Of course, that could just be me being overly cautious.

What site are you parodying? On second thought, it sounds like it would be better if I remain ignorant; and I suspect you are not being overly cautious in having some reservations.

Eric

···

On 2013/07/20 8:58 AM, Benjamin Root wrote:

Cheers!
Ben Root

On Jul 20, 2013 2:20 PM, "Eric Firing" <efiring@…229… > <mailto:efiring@…229…>> wrote:

    On 2013/07/20 4:18 AM, David P. Sanders wrote:
     > Hi,
     >
     > Probably many of you know about "Plot or Not", a site where we
    vote on
     > the same plot presented in different ways, to get feedback about
    better
     > matplotlibrc params:
     >
     > http://warm-escarpment-9042.herokuapp.com/
     >
     > It seems to me an absolutely fantastic idea! I think many people
    do not
     > realise how fantastic the plots can look with some of this modern
     > styling. (Styling was mentioned several times at SciPy.)
     >
     > Would it be possible to put a link to this site on the matplotlib web
     > page and encourage people to use it?

    David,

    Interesting, but I'm not sure this is a good approach. I really don't
    see the point of the voting. What I think would be more useful would be
    a set of matplotlibrc files with examples of their effect on at least a
    few plot types.

     >
     > Definitely time to update the defaults!!

    Or maybe include a representative set of rcParams combinations to make
    it easier for people to choose a design that suits their purpose. This
    could be part of a toolkit.

    Eric

     >
     > Best wishes,
     > David.
     >
     > –
     > Dr. David P. Sanders
     >
     > Profesor Titular "A" / Associate Professor
     > Departamento de F�sica, Facultad de Ciencias
     > Universidad Nacional Aut�noma de M�xico (UNAM)
     >
     > dpsanders@…1147… <mailto:dpsanders@…1147…>
    <mailto:dpsanders@…1147…>
     > http://sistemas.fciencias.unam.mx/~dsanders
     > <http://sistemas.fciencias.unam.mx/~dsanders>
     >
     > Cub�culo / office: #414, 4o. piso del Depto. de F�sica
     > Tel.: +52 55 5622 4965 <tel:%2B52%2055%205622%204965>
     >
    ------------------------------------------------------------------------------
     > 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
    <mailto:Matplotlib-devel@lists.sourceforge.net>
     > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
     >

    ------------------------------------------------------------------------------
    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
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Send Matplotlib-devel mailing list submissions to
        matplotlib-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
or, via email, send a message with subject or body 'help' to
        matplotlib-devel-request@lists.sourceforge.net

You can reach the person managing the list at
        matplotlib-devel-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Matplotlib-devel digest..."

Today's Topics:

   1. Re: Plot or Not: voting to create better matplotlibrc
      (Adrian Price-Whelan)

----------------------------------------------------------------------

Message: 1
Date: Sat, 20 Jul 2013 18:36:42 -0400
From: Adrian Price-Whelan <adrianmpw@...149...>
Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
        matplotlibrc
To: matplotlib-devel@lists.sourceforge.net
Message-ID:
        <CAEUL7mENjKC4ZYeSsm+7Yq7h4oYiA1nMPKi=
E9pM_rwMjVE-bg@...150...>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

Definitely don't link from matplotlib. This was a fun hack put together to
get people talking about re-styling -- success!

OK, sorry for the noise. The site is beautiful and functional, and I'm very
glad that you got the discussion flowing!

I have to echo Chris' disappointment about the discussion of defaults in

MPL. While there are certainly many subjective elements of style and
design, there are also a number of rules that the default settings violate
(as Chris mentions below). The way I interpret the push-back to replacing
the defaults is: "there are too many better alternatives that we will never
agree upon, so let's just keep what's there." To 0th order, just pick one!
Fixing the few things that Chris mentions below will go a long way to
modernizing the MPL feel and experience. There many other things I would
like to change about the defaults, but maybe the right thing to do is just
issue a pull request so we can discuss on there?

I agree about the defaults, we desperately need to modernize the look of
the plots to be competitive with ggplot2 etc.

As a longer term idea, I propose:
- normalize what can and can't be modified with an rc file -- right now,
it's kind of all over the place

I really do object to the 'rc' terminology.
According to http://en.wikipedia.org/wiki/Run_commands:

The term *rc* stands for the phrase "*run commands*". It is used for any

file that contains startup information for a

command. It is believed to have originated somewhere in 1965

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

At https://gist.github.com/dpsanders/6047005 I have uploaded a short script
which should be added to the matplotlib documentation, where I show how it
looks to use mpl_params.
I think it is much clearer and more inviting to tweak!

David.

···

On Sat, Jul 20, 2013 at 5:36 PM, < matplotlib-devel-request@lists.sourceforge.net> wrote:

then:
- each plot in the matplotlib gallery should have a drop-down menu with
~3-5 style options
- these options can be named or whatever, but should be complete
matplotlibrc files that can either be a) shipped with matplotlib, or b)
very easily downloaded and installed (think:
matplotlib.rc_install('name-of-style'))
- on each gallery entry page, selecting an option from the drop-down should
show the same plot made with the specified rc style

I'm happy to help implement this stuff, but I think this would be a
tremendous resource to the community.

And if you decide to reject everything from this email, *please* at least
change the default colormap :slight_smile: #downwithJet

- Adrian

From: Chris Beaumont <beaumont@…229…>
> Date: Sat, Jul 20, 2013 at 5:47 PM
> Subject: Re: Plot or Not: voting to create better matplotlibrc
> To: matplotlib-devel@lists.sourceforge.net
>
>
> Hi,
>
> I thought I'd chime in on this discussion – Adrian Price-Whelan and I
put
> together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib – the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams, nor
> does it systematically explore all possible styles. The votes (>10K,
last I
> checked) are saved, and eventually Adrian or I will look over the
feedback
> and report back to you all. I haven't had time for that yet. I hope the
> name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely
upon
> daily), I must admit I was disheartened after hearing the MPL devs at
SciPy
> discuss styles and defaults. I understand that you don't want to change
the
> default styles without a clearly better alternative. I also understand
> that, to some extent, style preferences are subjective. However, there
> seemed to be quite a bit of resistance to the idea that MPL defaults
should
> change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects
like
> ggplot2, d3, tableau, and spotfire do a "better" job than MPL at
styling),
> there are some well-established visual principles that matplotlib
violates.
> Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have this
> property – c and y are harder to see, and thus carry less visual
emphasis.
> A color table like the "Dark2" color brewer table (
> http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org) is more uniform, and carefully designed for visibility
> and contrast. 'rgbcmyk' is clearly an arbitrary choice – why not use a
> smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger – purple or yellow?), and
better
> at ordering changes in intensity or saturation. A colleague of mine
> designed a visualization tool for doctors, and found that the rainbow
color
> table had a dramatic negative effect on the effectiveness of the tool
(you
> can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>
> 3) Some of the defaults violate Tufte principles like minimizing "chart
> junk." For example, the 'stepfilled' mode for hist is probably better
than
> the default, which draws vertical lines between every bin. Those lines
make
> the histogram noisier – do they convey any extra information? Again,
this
> can't be tweaked via rcParams.
>
> Sorry for being long-winded – I just want to make the case that this is
> an important (and not *entirely* subjective) issue. If nothing else, it
> would be great to see some clear statement about where the MPL devs stand
> on this issue – what criteria must be met to consider a change to the
> defaults? My apologies if such a document already exists somewhere!
>
> Cheers,
> Chris Beaumont
>
>
>
>
>
> On Sat, Jul 20, 2013 at 3:03 PM, < > > matplotlib-devel-request@lists.sourceforge.net> wrote:
>
>> Send Matplotlib-devel mailing list submissions to
>> matplotlib-devel@lists.sourceforge.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> or, via email, send a message with subject or body 'help' to
>> matplotlib-devel-request@lists.sourceforge.net
>>
>> You can reach the person managing the list at
>> matplotlib-devel-owner@lists.sourceforge.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Matplotlib-devel digest…"
>>
>>
>> Today's Topics:
>>
>> 1. Re: Plot or Not: voting to create better matplotlibrc
>> (Eric Firing)
>> 2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
>> 3. Re: Plot or Not: voting to create better matplotlibrc
>> (Benjamin Root)
>> 4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 20 Jul 2013 08:20:11 -1000
>> From: Eric Firing <efiring@…229…>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> matplotlibrc
>> To: matplotlib-devel@lists.sourceforge.net
>> Message-ID: <51EAD4DB.5040906@…229…>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2013/07/20 4:18 AM, David P. Sanders wrote:
>> > Hi,
>> >
>> > Probably many of you know about "Plot or Not", a site where we vote on
>> > the same plot presented in different ways, to get feedback about
better
>> > matplotlibrc params:
>> >
>> > http://warm-escarpment-9042.herokuapp.com/
>> >
>> > It seems to me an absolutely fantastic idea! I think many people do
not
>> > realise how fantastic the plots can look with some of this modern
>> > styling. (Styling was mentioned several times at SciPy.)
>> >
>> > Would it be possible to put a link to this site on the matplotlib web
>> > page and encourage people to use it?
>>
>> David,
>>
>> Interesting, but I'm not sure this is a good approach. I really don't
>> see the point of the voting. What I think would be more useful would be
>> a set of matplotlibrc files with examples of their effect on at least a
>> few plot types.
>>
>> >
>> > Definitely time to update the defaults!!
>>
>> Or maybe include a representative set of rcParams combinations to make
>> it easier for people to choose a design that suits their purpose. This
>> could be part of a toolkit.
>>
>> Eric
>>
>> >
>> > Best wishes,
>> > David.
>> >
>> > –
>> > Dr. David P. Sanders
>> >
>> > Profesor Titular "A" / Associate Professor
>> > Departamento de F?sica, Facultad de Ciencias
>> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >
>> > dpsanders@…1147… <mailto:dpsanders@…1147…>
>> > http://sistemas.fciencias.unam.mx/~dsanders
>> > <http://sistemas.fciencias.unam.mx/~dsanders>
>> >
>> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> > Tel.: +52 55 5622 4965
>> >
>> >
>> >
>>
------------------------------------------------------------------------------
>> > 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
>> >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 20 Jul 2013 08:55:37 -1000
>> From: Eric Firing <efiring@…229…>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> plots?
>> To: matplotlib-devel@lists.sourceforge.net
>> Message-ID: <51EADD29.6080601@…229…>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2013/07/20 4:41 AM, David P. Sanders wrote:
>> > I find the default font used in matplotlib horrible. We should be able
>> > to do much better these days.
>>
>> Which font is being used as default on your installation? And what are
>> the characteristics that earn the rating of "horrible"?
>>
>> Eric
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 20 Jul 2013 14:58:12 -0400
>> From: Benjamin Root <ben.root@…553…>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> matplotlibrc
>> To: Eric Firing <efiring@…229…>
>> Cc: matplotlib development list
>> <matplotlib-devel@lists.sourceforge.net>
>> Message-ID:
>> <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
>> c4Qob7vJ5q-SrE7tcrqA@…150…>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> >From discussions with others at SciPy, we found ourselves disagreeing
on
>> what default we would want. We also weren't sure exactly which params
were
>> the ones that people tended to change. We have zero data on this. This
>> site
>> is intended to help start that data collection process.
>>
>> We can certainly improve this site to collect other kinds of info, but
>> this
>> is just a start. One could also view this as a launching point for
>> teaching
>> how to use rcParams (sorry David, i kinda like that name) in mpl. You
all
>> know I never let a good teaching moment go to waste!
>>
>> As for linking from matplotlib.org, I am ambivalent. It is a bit
>> gimmicky,
>> and I do worry about being counterproductive to efforts in SciPy to be
>> more
>> inclusive of women (given the rather anti-feministic undertones of the
>> site
>> we are parodying). Of course, that could just be me being overly
cautious.
>>
>> Cheers!
>> Ben Root
>> On Jul 20, 2013 2:20 PM, "Eric Firing" <efiring@…229…> wrote:
>>
>> > On 2013/07/20 4:18 AM, David P. Sanders wrote:
>> > > Hi,
>> > >
>> > > Probably many of you know about "Plot or Not", a site where we vote
on
>> > > the same plot presented in different ways, to get feedback about
>> better
>> > > matplotlibrc params:
>> > >
>> > > http://warm-escarpment-9042.herokuapp.com/
>> > >
>> > > It seems to me an absolutely fantastic idea! I think many people do
>> not
>> > > realise how fantastic the plots can look with some of this modern
>> > > styling. (Styling was mentioned several times at SciPy.)
>> > >
>> > > Would it be possible to put a link to this site on the matplotlib
web
>> > > page and encourage people to use it?
>> >
>> > David,
>> >
>> > Interesting, but I'm not sure this is a good approach. I really don't
>> > see the point of the voting. What I think would be more useful would
be
>> > a set of matplotlibrc files with examples of their effect on at least
a
>> > few plot types.
>> >
>> > >
>> > > Definitely time to update the defaults!!
>> >
>> > Or maybe include a representative set of rcParams combinations to make
>> > it easier for people to choose a design that suits their purpose.
This
>> > could be part of a toolkit.
>> >
>> > Eric
>> >
>> > >
>> > > Best wishes,
>> > > David.
>> > >
>> > > –
>> > > Dr. David P. Sanders
>> > >
>> > > Profesor Titular "A" / Associate Professor
>> > > Departamento de F?sica, Facultad de Ciencias
>> > > Universidad Nacional Aut?noma de M?xico (UNAM)
>> > >
>> > > dpsanders@…1147… <mailto:dpsanders@…1147…>
>> > > http://sistemas.fciencias.unam.mx/~dsanders
>> > > <http://sistemas.fciencias.unam.mx/~dsanders>
>> > >
>> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> > > Tel.: +52 55 5622 4965
>> > >
>> > >
>> > >
>> >
>>
------------------------------------------------------------------------------
>> > > 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
>> > >
>> >
>> >
>> >
>> >
>>
------------------------------------------------------------------------------
>> > 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
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed…
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sat, 20 Jul 2013 15:03:20 -0400
>> From: Benjamin Root <ben.root@…553…>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> plots?
>> To: "David P. Sanders" <dpsanders@…1147…>
>> Cc: matplotlib development list
>> <matplotlib-devel@lists.sourceforge.net>
>> Message-ID:
>> <CANNq6Fm0Oz=
>> 3ukXYH4yFA0qbHi2j7-sjdhkCzyrkU-4ELRdyow@…150…>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> David,
>>
>> IIRC, we were just starting to investigate how to produce retina
graphics.
>> Perhaps you might be able to help Mike D and Michael de Hoon with there
>> efforts because very few of us have retina displays.
>>
>> Cheers!
>> Ben Root
>> On Jul 20, 2013 10:43 AM, "David P. Sanders" < > dpsanders@…1147…> > >> wrote:
>>
>> > I find the default font used in matplotlib horrible. We should be able
>> to
>> > do much better these days.
>> >
>> > One very interesting option, at least for standard (paper) publishing,
>> is
>> > the STIX fonts, which is a Times-like font set promoted by several
>> > publishers.
>> >
>> > There are various options in matplotlib, such as
>> > matplotlib.rcParams["mathtext.fontset"], which allow the option
"stix",
>> > but I have not been able to get it to work. Can anybody please help me
>> with
>> > this – what is required?
>> >
>> > I have the STIX otf or ttf installed on my Mac, but I don't seem to
>> manage
>> > to get the LaTeX versions installed – installing LaTeX fonts is *so*
>> > disgusting (is there some helper script for that?).
>> >
>> > Thanks and best wishes,
>> > David.
>> >
>> > –
>> > Dr. David P. Sanders
>> >
>> > Profesor Titular "A" / Associate Professor
>> > Departamento de F?sica, Facultad de Ciencias
>> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >
>> > dpsanders@…1147…
>> > http://sistemas.fciencias.unam.mx/~dsanders
>> >
>> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> >
>> > Tel.: +52 55 5622 4965
>> >
>> >
>> >
>>
------------------------------------------------------------------------------
>> > 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
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed…
>>
>> ------------------------------
>>
>>
>>
------------------------------------------------------------------------------
>> 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
>>
>>
>> End of Matplotlib-devel Digest, Vol 86, Issue 17
>> ************************************************
>>
>
>
>
> –
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
>
>
> –
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>

--

Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
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

End of Matplotlib-devel Digest, Vol 86, Issue 19
************************************************

--
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)

dpsanders@...1147...
http://sistemas.fciencias.unam.mx/~dsanders

Cubículo / office: #414, 4o. piso del Depto. de Física

Tel.: +52 55 5622 4965

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

···

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

‘image.cmap’ – nice! Shows how much I know :slight_smile:

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 <efiring@…229…> 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


'image.cmap' -- nice! Shows how much I know :slight_smile:

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.

I whole-heartedly agree.

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.

This is already implemented! The problem is, it's hidden away in the
mpltools toolkit:

http://tonysyu.github.io/mpltools/

which nobody seems to know about or use, which is a great shame, since it's
first class -- great job, Tony!

The first example there is:

from mpltools import style>>> style.use('ggplot')

and then the plot is suddenly jaw-droppingly beautiful!

This is achieved with style files which just have lists of matplotlib
params like this:

patch.linewidth = 0.5
patch.facecolor = '#348ABD' # blue
patch.edgecolor = '#EEEEEE'
patch.antialiased = True

These are parsed using the ConfigObj package (this package parses config
files of this type).

Somebody (Chris?) tweeted something about the Vega package earlier:
http://trifacta.github.io/vega/

They seem to have these kind of things solved already (disclaimer: I only
browsed briefly their site) using JSON, but actually Tony's approach seems
like a winner.

mpltools may be installed with

pip install ConfigObj
pip install mpltools

[For some reason the dependency on ConfigObj is not registered in mpltools.
Tony, are you the packager?]

This is all *crying out* to be dropped straight into matplotlib proper!

David

···

On Sat, Jul 20, 2013 at 8:48 PM, Chris Beaumont <beaumont@...229...> wrote:

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 <efiring@...229...> 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

--
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)

dpsanders@...1147...
http://sistemas.fciencias.unam.mx/~dsanders

Cubículo / office: #414, 4o. piso del Depto. de Física

Tel.: +52 55 5622 4965

Regarding whole sets of rcParams, you may want to look at this:
https://github.com/tonysyu/mpltools

Kevin
···

On 07/20/2013 09:48 PM, Chris Beaumont
wrote:

‘image.cmap’ – nice! Shows how much I know :slight_smile:

      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 <efiring@…229…>
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](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](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](http://www.ifa.hawaii.edu/%7Ebeaumont)

    ************************************
------------------------------------------------------------------------------
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!
_______________________________________________
Matplotlib-devel mailing list

http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrkMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel

<snip>

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.

This is already implemented! The problem is, it's hidden away in the
mpltools toolkit:

http://tonysyu.github.io/mpltools/

which nobody seems to know about or use, which is a great shame, since
it's first class -- great job, Tony!

The first example there is:

>>> from mpltools import style>>> style.use('ggplot')

and then the plot is suddenly jaw-droppingly beautiful!

This is achieved with style files which just have lists of matplotlib
params like this:

patch.linewidth = 0.5
patch.facecolor = '#348ABD' # blue
patch.edgecolor = '#EEEEEE'
patch.antialiased = True

These are parsed using the ConfigObj package (this package parses config
files of this type).

Somebody (Chris?) tweeted something about the Vega package earlier:
http://trifacta.github.io/vega/

They seem to have these kind of things solved already (disclaimer: I only
browsed briefly their site) using JSON, but actually Tony's approach seems
like a winner.

mpltools may be installed with

> pip install ConfigObj
> pip install mpltools

[For some reason the dependency on ConfigObj is not registered in
mpltools. Tony, are you the packager?]

I'm not really sure why the configobj dependency doesn't resolve properly.
As they say: pull requests are welcome. :wink:

This is all *crying out* to be dropped straight into matplotlib proper!

Here's a PR to add the style sheets from mpltools:
https://github.com/matplotlib/matplotlib/pull/2236

(using matplotlib's parser instead of ConfigObj)

Cheers!
-Tony

···

On Sat, Jul 20, 2013 at 9:10 PM, David P. Sanders < dpsanders@...1147...> wrote:

On Sat, Jul 20, 2013 at 8:48 PM, Chris Beaumont <beaumont@...229...>wrote:

David

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".

I agree those are better. This is *such* a core method, though, that the old name can probably never go away -- there are tons of references to it in the documentation that would need to be updated, not to mention all of the non-documentation information (mailing list, stackoverflow) that Google finds. I worry that adding an alias will actually contribute to confusion, not eliminate it. I'd prefer to make it more obvious what it is and does in the documentation rather than change its name.

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.

My biggest pet peeve is the way that some parameters take effect at "construction time" and thus their changes have no effect on existing plots. Some take effect at draw time, and are thus more dynamic. We should strive for the latter whenever possible. Some things are just required to be the former, so these should be documented clearly as exceptions.

As for a low-hanging fruit project, the formatting of matplotlibrc.template is a mess. It would be great if someone could go through it and make the line lengths and tabbing consistent etc.

Mike

···

On 07/20/2013 09:07 PM, Eric Firing wrote:

On 2013/07/20 2:38 PM, David P. Sanders wrote:

As one small data point here, from a really excellent paper reviewing
the trade-offs in colormap design and deriving the "cool-warm"
colormap as a good default:

"This diverging color map interpolation has also been added to
ParaView, a free, open-source end-user scientific visualization
application, and was first featured in the 3.4 release in October
2008. Although ParaView does let users change the color map and there
is no way to track who does so, in our experience few users actually
do this. In the nearly 3000 messages on the ParaView users’ mailing
list from October 2008 to July 2009, there was no mention of the
change of color map from rainbow to cool-warm diverging. Users seem to
have accepted the change with little notice despite most users’
affinity for rainbow color maps."

- http://www.cs.unm.edu/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf

It absolutely should be easy to go back to the way things were, for
reproduction of old carefully hand-tweaked plots etc. But, there are
cases where our defaults are demonstrably terrible; and, these
defaults are demonstrably the direct cause of people producing
unnecessarily inferior plots; and, it's been many years now that this
situation has continued out and nothing has happened because we don't
want to be hasty. At some point we need to bite the bullet and make
these things better.

-n

···

On Sun, Jul 21, 2013 at 2:48 AM, Chris Beaumont <beaumont@...229...> wrote:

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.