matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[David P. S. <dps...@ci...>]

On Sat, Jul 20, 2013 at 5:36 PM, <
mat...@li...> wrote:

> Send Matplotlib-devel mailing list submissions to
>         mat...@li...
>
> 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
>         mat...@li...
>
> You can reach the person managing the list at
>         mat...@li...
>
> 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 <adr...@gm...>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>         matplotlibrc
> To: mat...@li...
> Message-ID:
>         <CAEUL7mENjKC4ZYeSsm+7Yq7h4oYiA1nMPKi=
> E9p...@ma...>
> 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.



>
> 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 :) #downwithJet
>
> - Adrian
>
> From: Chris Beaumont <bea...@ha...>
> > Date: Sat, Jul 20, 2013 at 5:47 PM
> > Subject: Re: Plot or Not: voting to create better matplotlibrc
> > To: mat...@li...
> >
> >
> > 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, <
> > mat...@li...> wrote:
> >
> >> Send Matplotlib-devel mailing list submissions to
> >>         mat...@li...
> >>
> >> 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
> >>         mat...@li...
> >>
> >> You can reach the person managing the list at
> >>         mat...@li...
> >>
> >> 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 <ef...@ha...>
> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
> >>         matplotlibrc
> >> To: mat...@li...
> >> Message-ID: <51E...@ha...>
> >> 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)
> >> >
> >> > dps...@ci... <mailto:dps...@ci...>
> >> > 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
> >> > Mat...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >> >
> >>
> >>
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Sat, 20 Jul 2013 08:55:37 -1000
> >> From: Eric Firing <ef...@ha...>
> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
> >>         plots?
> >> To: mat...@li...
> >> Message-ID: <51E...@ha...>
> >> 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...@ou...>
> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
> >>         matplotlibrc
> >> To: Eric Firing <ef...@ha...>
> >> Cc: matplotlib development list
> >>         <mat...@li...>
> >> Message-ID:
> >>         <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
> >> c4Q...@ma...>
> >> 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" <ef...@ha...> 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)
> >> > >
> >> > > dps...@ci... <mailto:dps...@ci...>
> >> > > 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
> >> > > Mat...@li...
> >> > > 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
> >> > Mat...@li...
> >> > 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...@ou...>
> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
> >>         plots?
> >> To: "David P. Sanders" <dps...@ci...>
> >> Cc: matplotlib development list
> >>         <mat...@li...>
> >> Message-ID:
> >>         <CANNq6Fm0Oz=
> >> 3uk...@ma...>
> >> 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" <
> dps...@ci...>
> >> 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)
> >> >
> >> > dps...@ci...
> >> > 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
> >> > Mat...@li...
> >> > 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
> >> Mat...@li...
> >> 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
> Mat...@li...
> 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)

dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders

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

Tel.: +52 55 5622 4965

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Eric F. <ef...@ha...>]

On 2013/07/20 11:47 AM, Chris Beaumont wrote:
> 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 <http://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

Chris,

I appreciate the ideas, and I agree entirely that improvements are in 
order, so it is just a question of exactly what and how, not whether 
there should be changes.  (For example, the default line color set often 
irritates me, too, because blue and green look rather similar, 
particularly in comparison to red, which visually overwhelms the others.)

A problem with simply changing the defaults to some sort of consensus or 
majority opinion as to what is better is that inevitably there will be 
users who will be distressed when they upgrade and suddenly find that 
all their plots--perhaps generated automatically by their cron jobs or 
web apps--look very different, and perhaps don't even work well with the 
new defaults.  Therefore we have to be somewhat conservative, and the 
tendency is to minimize changes that are not essential.  I think that a 
change in the defaults will need to be staged in such a fashion that it 
will be as easy as possible for users to retain the old defaults if they 
prefer them.  That leads to the idea that something like a style toolkit 
or cookbook, or set of examples included with mpl, might be helpful. 
There is never going to be one good style for all; it would be good to 
have examples of how to tailor things for the screen, or for paper, or 
for presentations, or for publications (some of which still favor black 
and white).

The mpl examples (gallery) can be the first target for improvement; 
based on some experience and input, an actual change in the defaults 
might be announced and scheduled for some future release, with assurance 
that a matplotlibrc file for the old defaults will remain available for 
some interval.

Eric

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Adrian Price-W. <adr...@gm...>]

Hi,

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

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?

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

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 :) #downwithJet

- Adrian

From: Chris Beaumont <bea...@ha...>
> Date: Sat, Jul 20, 2013 at 5:47 PM
> Subject: Re: Plot or Not: voting to create better matplotlibrc
> To: mat...@li...
>
>
> 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, <
> mat...@li...> wrote:
>
>> Send Matplotlib-devel mailing list submissions to
>>         mat...@li...
>>
>> 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
>>         mat...@li...
>>
>> You can reach the person managing the list at
>>         mat...@li...
>>
>> 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 <ef...@ha...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>>         matplotlibrc
>> To: mat...@li...
>> Message-ID: <51E...@ha...>
>> 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)
>> >
>> > dps...@ci... <mailto:dps...@ci...>
>> > 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
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 20 Jul 2013 08:55:37 -1000
>> From: Eric Firing <ef...@ha...>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>>         plots?
>> To: mat...@li...
>> Message-ID: <51E...@ha...>
>> 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...@ou...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>>         matplotlibrc
>> To: Eric Firing <ef...@ha...>
>> Cc: matplotlib development list
>>         <mat...@li...>
>> Message-ID:
>>         <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
>> c4Q...@ma...>
>> 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" <ef...@ha...> 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)
>> > >
>> > > dps...@ci... <mailto:dps...@ci...>
>> > > 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
>> > > Mat...@li...
>> > > 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
>> > Mat...@li...
>> > 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...@ou...>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>>         plots?
>> To: "David P. Sanders" <dps...@ci...>
>> Cc: matplotlib development list
>>         <mat...@li...>
>> Message-ID:
>>         <CANNq6Fm0Oz=
>> 3uk...@ma...>
>> 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" <dps...@ci...>
>> 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)
>> >
>> > dps...@ci...
>> > 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
>> > Mat...@li...
>> > 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
>> Mat...@li...
>> 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

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Chris B. <bea...@ha...>]

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, <
mat...@li...> wrote:

> Send Matplotlib-devel mailing list submissions to
>         mat...@li...
>
> 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
>         mat...@li...
>
> You can reach the person managing the list at
>         mat...@li...
>
> 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 <ef...@ha...>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>         matplotlibrc
> To: mat...@li...
> Message-ID: <51E...@ha...>
> 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)
> >
> > dps...@ci... <mailto:dps...@ci...>
> > 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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 20 Jul 2013 08:55:37 -1000
> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>         plots?
> To: mat...@li...
> Message-ID: <51E...@ha...>
> 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...@ou...>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>         matplotlibrc
> To: Eric Firing <ef...@ha...>
> Cc: matplotlib development list
>         <mat...@li...>
> Message-ID:
>         <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
> c4Q...@ma...>
> 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" <ef...@ha...> 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)
> > >
> > > dps...@ci... <mailto:dps...@ci...>
> > > 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
> > > Mat...@li...
> > > 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
> > Mat...@li...
> > 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...@ou...>
> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>         plots?
> To: "David P. Sanders" <dps...@ci...>
> Cc: matplotlib development list
>         <mat...@li...>
> Message-ID:
>         <CANNq6Fm0Oz=
> 3uk...@ma...>
> 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" <dps...@ci...>
> 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)
> >
> > dps...@ci...
> > 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
> > Mat...@li...
> > 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
> Mat...@li...
> 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
************************************

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Eric F. <ef...@ha...>]

On 2013/07/20 8:58 AM, Benjamin Root wrote:
>  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

>
> Cheers!
> Ben Root
>
> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...
> <mailto:ef...@ha...>> 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)
>      >
>      > dps...@ci... <mailto:dps...@ci...>
>     <mailto:dps...@ci... <mailto:dps...@ci...>>
>      > 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 <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
>      > Mat...@li...
>     <mailto:Mat...@li...>
>      > 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
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] How to use STIX fonts in matplotlib plots?

[Benjamin R. <ben...@ou...>]

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" <dps...@ci...>
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)
>
> dps...@ci...
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Benjamin R. <ben...@ou...>]

>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" <ef...@ha...> 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)
> >
> > dps...@ci... <mailto:dps...@ci...>
> > 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
> > Mat...@li...
> > 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] How to use STIX fonts in matplotlib plots?

[Eric F. <ef...@ha...>]

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

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Eric F. <ef...@ha...>]

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)
>
> dps...@ci... <mailto:dps...@ci...>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] How to use STIX fonts in matplotlib plots?

[David P. S. <dps...@ci...>]

Example script for using mathtext.fontset:

import matplotlib as mpl
import numpy as np
from matplotlib import pyplot as plt

mpl.rcParams["mathtext.fontset"] = "stix"

x = np.arange(-5, 5, 0.01)
y = x*x

plt.plot(x, y)
plt.xlabel(r"$x$")
plt.ylabel(r"$x^2$")
plt.show()

Apparently the axis labels are correctly rendered using STIX fonts, *but*
in a bitmapped way (?). At least, on my retina screen the labels look fuzzy.

How can I change also the tic labels to use STIX fonts?

By the way, the following is a useful idiom to search for relevant
parameters in the rcParams:

[k for k in mpl.rcParams.keys() if 'font' in k]

I think it would be useful to document this -- where would be a good place?

Finally, could somebody please explain what 'rc' means? This does not seem
like a good name to me.
I know it comes from the UNIX world, but I couldn't find an explanation for
'rc' on Wikipedia.

OK, I found it:
http://www.catb.org/jargon/html/R/rc-file.html

This is not good -- there is *no* reason to use the nomenclature 'rc'; this
is just confusing for users who find it arcane and unwelcoming (I speak
from experience).

Could it not just be called
mpl.parameters,   or  mpl.mpl_parameters,
or something like that?


Best,
David






On Sat, Jul 20, 2013 at 9:41 AM, David P. Sanders <
dps...@ci...> 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)
>
> dps...@ci...
> http://sistemas.fciencias.unam.mx/~dsanders
>
> Cubículo / office: #414, 4o. piso del Depto. de Física
>
> Tel.: +52 55 5622 4965
>



-- 
Dr. David P. Sanders

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

dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders

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

Tel.: +52 55 5622 4965

[matplotlib-devel] How to use STIX fonts in matplotlib plots?

[David P. S. <dps...@ci...>]

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)

dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders

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

Tel.: +52 55 5622 4965

[matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[David P. S. <dps...@ci...>]

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)

dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders

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

Tel.: +52 55 5622 4965

[matplotlib-devel] 1.3.0rc5 tagged

[Michael D. <md...@st...>]

At long last, I have a 1.3.0rc5 tagged.  I really hope to the software 
deities that this is the last rc before final.

If you wouldn't mind creating and posting the binaries, I'll make an 
announcment on matplotlib-users, give this a week and then put final out.

Cheers,
Mike

Re: [matplotlib-devel] Results of matplotlib user survey 2013

[Michael D. <md...@st...>]

Apologies: I didn't realize the link to the raw results only exists for 
users with edit permissions.  The public URL for the raw results is:

https://docs.google.com/spreadsheet/ccc?key=0AjrPjlTMRTwTdHpQS25pcTZIRWdqX0pNckNSU01sMHc&usp=sharing

Mike

On 07/18/2013 09:42 AM, Michael Droettboom wrote:
> We have had 508 responses to the matplotlib user survey.  Quite a nice 
> turnout!
>
> You can view the results here:
>
> https://docs.google.com/spreadsheet/viewanalytics?key=0AjrPjlTMRTwTdHpQS25pcTZIRWdqX0pNckNSU01sMHc&gridId=0#chart
>
> and from there, you can access the complete raw results.
>
> I will be doing more analysis of the results over the coming days and 
> weeks, including dedup'ing some of the responses and converting some 
> of the free-form responses into github issues etc.  Volunteers to help 
> with this are of course welcome!
>
> Cheers,
> Mike

[matplotlib-devel] Results of matplotlib user survey 2013

[Michael D. <md...@st...>]

We have had 508 responses to the matplotlib user survey.  Quite a nice 
turnout!

You can view the results here:

https://docs.google.com/spreadsheet/viewanalytics?key=0AjrPjlTMRTwTdHpQS25pcTZIRWdqX0pNckNSU01sMHc&gridId=0#chart

and from there, you can access the complete raw results.

I will be doing more analysis of the results over the coming days and 
weeks, including dedup'ing some of the responses and converting some of 
the free-form responses into github issues etc.  Volunteers to help with 
this are of course welcome!

Cheers,
Mike

Re: [matplotlib-devel] Reorganizing axes plot methods

[Nelle V. <nel...@gm...>]

On 18 July 2013 15:27, Michael Droettboom <md...@st...> wrote:

> On 07/17/2013 04:57 PM, Eric Firing wrote:
> > On 2013/07/17 3:14 AM, Michael Droettboom wrote:
> >> Yes.  This is great work!
> >>
> >> Just to chime in (after having been away for most of this conversation)
> -->
> >>
> >> I think we can do this reorganization now without introducing any
> >> implicit (or otherwise) use of gca()/pyplot stuff in the Axes class
> >> methods.  Refactoring how the pyplot wrapper is done can be done as a
> >> separate project at a later time (or even in parallel if someone wants
> >> to, since all of Nelle's work at the end of the day doesn't change the
> >> Axes interface).
> >>
> >> My only other comment (and I mentioned this in PR #2213 as well) is that
> >> having the short stub functions in the Axes class in addition to the
> >> actual implementations elsewhere introduces a new
> >> synchronization/maintenance problem between the two.  Maybe it makes
> >> sense to merely add the implementation functions to the Axes class
> >> namespace dynamically.  Magical, sure, but should have ultimately the
> >> same result as far as introspection, autocompletion and other IPython
> >> goodness is concerned.
> >>
> >> Mike
> > Mike,
> >
> > One other option is to have the new private modules include mixin
> > classes from which Axes would inherit methods.  There would be a lot of
> > mixins, and this would be an example of the dreaded multiple
> > inheritance, but it would be simple and explicit, with no magic.
> >
> > Eric
> >
> >
> I think either approach is fine as far as I'm concerned, though what
> Eric suggests is probably a bit simpler in terms of lines of code.
>

I'm attempting an implementation of
https://github.com/matplotlib/matplotlib/pull/2213 using mixins, to get my
head around this idea.
I'll keep you posted on the code.


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

Re: [matplotlib-devel] closing (and opening) the user survey?

[Michael D. <md...@st...>]

I'm fine with that.  I actually had the same idea yesterday.  I don't 
think we'll get many more responses than we already have.

I'll go ahead close the survey and then make an official announcement on 
the usual channels.

Mike

On 07/17/2013 06:12 PM, Paul Ivanov wrote:
> Hey everyone,
>
> I hope this email finds you well. I got a request today from
> someone wanting to look at the survey results. How do you feel
> about just sharing the full document? We're at 580 responses
> right now, and it's been really a slow trickle in last couple of
> weeks after the initial splash. Or we could do another round on
> twitter and G+ and say the survey will be closed at the end of
> the month, and then release the results.
>
> Thoughts?
>
> best,

Re: [matplotlib-devel] Reorganizing axes plot methods

[Michael D. <md...@st...>]

On 07/17/2013 04:57 PM, Eric Firing wrote:
> On 2013/07/17 3:14 AM, Michael Droettboom wrote:
>> Yes.  This is great work!
>>
>> Just to chime in (after having been away for most of this conversation) -->
>>
>> I think we can do this reorganization now without introducing any
>> implicit (or otherwise) use of gca()/pyplot stuff in the Axes class
>> methods.  Refactoring how the pyplot wrapper is done can be done as a
>> separate project at a later time (or even in parallel if someone wants
>> to, since all of Nelle's work at the end of the day doesn't change the
>> Axes interface).
>>
>> My only other comment (and I mentioned this in PR #2213 as well) is that
>> having the short stub functions in the Axes class in addition to the
>> actual implementations elsewhere introduces a new
>> synchronization/maintenance problem between the two.  Maybe it makes
>> sense to merely add the implementation functions to the Axes class
>> namespace dynamically.  Magical, sure, but should have ultimately the
>> same result as far as introspection, autocompletion and other IPython
>> goodness is concerned.
>>
>> Mike
> Mike,
>
> One other option is to have the new private modules include mixin
> classes from which Axes would inherit methods.  There would be a lot of
> mixins, and this would be an example of the dreaded multiple
> inheritance, but it would be simple and explicit, with no magic.
>
> Eric
>
>
I think either approach is fine as far as I'm concerned, though what 
Eric suggests is probably a bit simpler in terms of lines of code.

Mike

Re: [matplotlib-devel] closing (and opening) the user survey?

[Nelle V. <nel...@gm...>]

> It was me :-)
>
> Only a day to day user who follow matplotlib (and other famous libs)
> development. I clicked on the survey thinking it was public. Anyway it was
> only curiosity so if you prefer keep it secret, it's cool for me !
>
> Keep the good work guys !!!
>

You could provide the "summary view" of the results: google doc generates
this view automatically, with nice charts etc, and updates it. For people a
bit curious, it's a nice way to have a quick feedback without having to run
any analyses of the results or to close the survey.


>
>
> --
> HadiM
>
>
> On Thu, Jul 18, 2013 at 12:12 AM, Paul Ivanov <pi...@be...> wrote:
>
>> Hey everyone,
>>
>> I hope this email finds you well. I got a request today from
>> someone wanting to look at the survey results. How do you feel
>> about just sharing the full document? We're at 580 responses
>> right now, and it's been really a slow trickle in last couple of
>> weeks after the initial splash. Or we could do another round on
>> twitter and G+ and say the survey will be closed at the end of
>> the month, and then release the results.
>>
>> Thoughts?
>>
>> best,
>> --
>>                    _
>>                   / \
>>                 A*   \^   -
>>              ,./   _.`\\ / \
>>             / ,--.S    \/   \
>>            /  `"~,_     \    \
>>      __o           ?
>>    _ \<,_         /:\
>> --(_)/-(_)----.../ | \
>> --------------.......J
>> Paul Ivanov
>> http://pirsquared.org
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] closing (and opening) the user survey?

[HadiM <mar...@gm...>]

It was me :-)

Only a day to day user who follow matplotlib (and other famous libs)
development. I clicked on the survey thinking it was public. Anyway it was
only curiosity so if you prefer keep it secret, it's cool for me !

Keep the good work guys !!!


--
HadiM


On Thu, Jul 18, 2013 at 12:12 AM, Paul Ivanov <pi...@be...> wrote:

> Hey everyone,
>
> I hope this email finds you well. I got a request today from
> someone wanting to look at the survey results. How do you feel
> about just sharing the full document? We're at 580 responses
> right now, and it's been really a slow trickle in last couple of
> weeks after the initial splash. Or we could do another round on
> twitter and G+ and say the survey will be closed at the end of
> the month, and then release the results.
>
> Thoughts?
>
> best,
> --
>                    _
>                   / \
>                 A*   \^   -
>              ,./   _.`\\ / \
>             / ,--.S    \/   \
>            /  `"~,_     \    \
>      __o           ?
>    _ \<,_         /:\
> --(_)/-(_)----.../ | \
> --------------.......J
> Paul Ivanov
> http://pirsquared.org
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] closing (and opening) the user survey?

[Paul I. <pi...@be...>]

Hey everyone,

I hope this email finds you well. I got a request today from
someone wanting to look at the survey results. How do you feel
about just sharing the full document? We're at 580 responses
right now, and it's been really a slow trickle in last couple of
weeks after the initial splash. Or we could do another round on
twitter and G+ and say the survey will be closed at the end of
the month, and then release the results.

Thoughts?

best,
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

Re: [matplotlib-devel] Reorganizing axes plot methods

[Eric F. <ef...@ha...>]

On 2013/07/17 3:14 AM, Michael Droettboom wrote:
> Yes.  This is great work!
>
> Just to chime in (after having been away for most of this conversation) -->
>
> I think we can do this reorganization now without introducing any
> implicit (or otherwise) use of gca()/pyplot stuff in the Axes class
> methods.  Refactoring how the pyplot wrapper is done can be done as a
> separate project at a later time (or even in parallel if someone wants
> to, since all of Nelle's work at the end of the day doesn't change the
> Axes interface).
>
> My only other comment (and I mentioned this in PR #2213 as well) is that
> having the short stub functions in the Axes class in addition to the
> actual implementations elsewhere introduces a new
> synchronization/maintenance problem between the two.  Maybe it makes
> sense to merely add the implementation functions to the Axes class
> namespace dynamically.  Magical, sure, but should have ultimately the
> same result as far as introspection, autocompletion and other IPython
> goodness is concerned.
>
> Mike

Mike,

One other option is to have the new private modules include mixin 
classes from which Axes would inherit methods.  There would be a lot of 
mixins, and this would be an example of the dreaded multiple 
inheritance, but it would be simple and explicit, with no magic.

Eric

[matplotlib-devel] MEP19: Continuous Integration

[Michael D. <md...@st...>]

I've started a MEP related to improving our continuous integration 
system for matplotlib.

https://github.com/matplotlib/matplotlib/wiki/Mep19

Rather than deal to much with implementation at this point, I thought it 
best to start by outlining our requirements.  At this point, let's just 
get everything we'd like in, and we can worry about prioritizing things 
later.

Once that's done, we can start discussing how to get things set up. We 
have some donation money to use for buying machines or paying for 
services, so we are not limited to what is available for free.  I would 
particularly like feedback from others who have set up similar things.  
I have some experience with ShiningPanda (a service based on Jenkins), 
and Travis.  We used buildbot in the past, but I have little direct 
experience with it.  Are there other obvious candidates or approaches?

Mike

Re: [matplotlib-devel] Reorganizing axes plot methods

[Michael D. <md...@st...>]

Yes.  This is great work!

Just to chime in (after having been away for most of this conversation) -->

I think we can do this reorganization now without introducing any 
implicit (or otherwise) use of gca()/pyplot stuff in the Axes class 
methods.  Refactoring how the pyplot wrapper is done can be done as a 
separate project at a later time (or even in parallel if someone wants 
to, since all of Nelle's work at the end of the day doesn't change the 
Axes interface).

My only other comment (and I mentioned this in PR #2213 as well) is that 
having the short stub functions in the Axes class in addition to the 
actual implementations elsewhere introduces a new 
synchronization/maintenance problem between the two.  Maybe it makes 
sense to merely add the implementation functions to the Axes class 
namespace dynamically.  Magical, sure, but should have ultimately the 
same result as far as introspection, autocompletion and other IPython 
goodness is concerned.

Mike

On 07/11/2013 11:47 PM, Tony Yu wrote:
> Nelle, this is great! Thanks for getting the ball rolling!
>
> Cheers,
> -Tony
>
>
> On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux 
> <nel...@gm... <mailto:nel...@gm...>> wrote:
>
>     FYI, I have started the refactoring we discussed at scipy. I think
>     what tony is suggesting is the same thing.
>
>     I've created a "work in progress" pull request:
>     https://github.com/matplotlib/matplotlib/pull/2213
>
>     In the refactoring we discussed at Scipy, we did not mention the
>     pyplots wrapper at all. It does not impact pyplot or the axes module
>     at all as it doesn't change the API at all. If we want to do something
>     more in depth that impacts the API, I think it would be worth writing
>     a MEP.
>
>     Thanks,
>     N
>
>
>     On 11 July 2013 13:12, Anton Akhmerov <ant...@gm...
>     <mailto:ant...@gm...>> wrote:
>     > Eric Firing <efiring@...> writes:
>     >>
>     >> Anton,
>     >>
>     >> Yes, I have done things like that in my own code, and basemap has a
>     >> similar ability to call gca() when an Axes is not supplied.
>      One can
>     >> even perform the pyplot import on an as-needed basis instead of
>     raising
>     >> an error. Nevetheless, it still represents what I view as a big
>     change
>     >> in mpl design, scrambling the state machine pyplot layer into
>     the OO
>     >> layer.  Sometimes this sort of thing is good, sometimes it
>     isn't.  In
>     >> the present case, I am far from convinced that it would be good.  I
>     >> don't see any real benefit at all over the present design.  I
>     think that
>     >> for the sanity of the developers, if nothing else, it is
>     important to
>     >> maintain some clear layering and hierarchy.
>     >>
>     >> Eric
>     >>
>     >
>     > I completely agree with that, and I just wanted to point out the
>     possibility.
>     > With the proposed separation of the plots to a separate module,
>     I think, the
>     > reasonable thing for pyplot would be to wrap the corresponding
>     plot functions
>     > by feeding gca into the axis argument.
>     >
>     > PS for what I think, pyplot right now is way too thick of a layer,
>     > obstructing an API use of backends.
>     >
>     > Anton
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > 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
>     > Mat...@li...
>     <mailto:Mat...@li...>
>     > 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
>     Mat...@li...
>     <mailto:Mat...@li...>
>     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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] basemap installation problem with mpl master

[Michael D. <md...@st...>]

Sorry to just be getting to this discussion now, after a vacation.

The move to setuptools was discussed at length as part of MEP11. See 
here: https://github.com/matplotlib/matplotlib/wiki/MEP11 and the MEP11 
mailing list thread.

It has been a long standing bug that we ship Python dependencies along 
with matplotlib.  Users were reporting pyparsing bugs to matplotlib, 
assuming it was a matplotlib project, etc.  That was the primary impetus 
for moving to setuptools: so that pip dependency resolution would work.  
It has not been without headaches -- the "remerge" of distribute back 
into setuptools in particular was handled really poorly by upstream.  I 
do hope that now that the community has re-coalesed around the "new" 
setuptools and the move from eggs to wheels that things will get better 
in the near future.  But I still think the new approach is far better 
than what we had.

Sorry that the namespace package declaration was missed and fell through 
the cracks, but I'm glad we noticed it before 1.3.0 final.  Is it the 
case that PR #2210, or are there still issues to be resolved?

Mike

On 07/06/2013 01:59 PM, Jeff Whitaker wrote:
>> Thomas Kluyver <mailto:th...@kl...>
>> July 6, 2013 11:26 AM
>>
>> *distribute*, which was a fork of setuptools, was merged into 
>> setuptools. *distutils* is the component in the standard library, and 
>> is still there. I still prefer distutils where possible, precisely 
>> because setuptools' eggs are a mess.
>>
>> Thomas
>
> I agree eggs are a mess.   Given that it is still easy to have the old 
> behavior, can someone explain why the change was made to have setup.py 
> create eggs by default?
>
> -Jeff
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> Damon McDougall <mailto:dam...@gm...>
>> July 6, 2013 11:20 AM
>>
>>
>>
>> On Sat, Jul 6, 2013 at 11:04 AM, Jeff Whitaker <js...@fa... 
>> <mailto:js...@fa...>> wrote:
>>
>>>     Damon McDougall <mailto:dam...@gm...>
>>>     July 6, 2013 9:32 AM
>>>
>>>
>>>
>>>         If I do a clean install of mpl master, and then of basemap,
>>>         basemap
>>>         lands in dist-packages/mpl_toolkits, as it always has.  But
>>>         now it is
>>>         not found--I can't import it.  It seems that now the *real*
>>>         mpl_toolkits
>>>         is cleverly hidden inside an egg directory with a monstrous
>>>         name,
>>>         leaving basemap orphaned in a directory with no __init__.py.
>>>          As a
>>>         workaround I can symlink it into the egg location.  I
>>>         suspect the real
>>>         solution will require basemap to use setuptools, correct?  I
>>>         don't know
>>>         how to do this, so I hope someone who does will submit a PR.
>>>
>>>
>>>     Actually, using the new setuptools isn't adequate, I just tried
>>>     it locally on my machine and it still doesn't install itself
>>>     into the matplotlib egg.
>>>
>>>     I think the proper solution here is to add basemap as an
>>>     optional dependency to matplotlib and have the user set a flag
>>>     (off by default) to pull basemap if it's desired
>>>
>>>     Does that sound like a reasonable solution?
>>
>>     What if a user decides later that he/she wants to install
>>     basemap?  Then they would have to reinstall matplotlib?  That
>>     doesn't sound reasonable to me.
>>
>>
>> Actually, on reflection, I'm in agreement with you.  I'm comfortable 
>> installing from source but this poses a larger problem when users 
>> download the basemap binary and expect it to Just Work.
>>
>>     How about having matplotlib install a symlink to the egg location?
>>
>>
>> If there's a way for setuptools to modify the matplotlib egg to add a 
>> symlink, then it must be possible for setuptools to just put the 
>> files there.  I just haven't figured out how to do that.
>>
>>     Why the change to using setuptools by default in the first place?
>>
>>
>> Long story.  The short story is that distutils was merged into 
>> setuptools.  So setuptools is now the recommended way to install 
>> python packages.
>>
>>
>>     -Jeff
>>>
>>>     P.S.  Note that the other mpl_toolkits are installed into the
>>>     correct place because they are shipped with matplotlib and
>>>     installed at the same time.  We could ship basemap with
>>>     matplotlib too but it's a rather large download.
>>>
>>>     Best wishes,
>>>     Damon
>>>
>>>     -- 
>>>     Damon McDougall
>>>     http://www.damon-is-a-geek.com
>>>     Institute for Computational Engineering Sciences
>>>     201 E. 24th St.
>>>     Stop C0200
>>>     The University of Texas at Austin
>>>     Austin, TX 78712-1229
>>>     Eric Firing <mailto:ef...@ha...>
>>>     July 6, 2013 12:53 AM
>>>     If I do a clean install of mpl master, and then of basemap,
>>>     basemap lands in dist-packages/mpl_toolkits, as it always has. 
>>>     But now it is not found--I can't import it.  It seems that now
>>>     the *real* mpl_toolkits is cleverly hidden inside an egg
>>>     directory with a monstrous name, leaving basemap orphaned in a
>>>     directory with no __init__.py.  As a workaround I can symlink it
>>>     into the egg location.  I suspect the real solution will require
>>>     basemap to use setuptools, correct?  I don't know how to do
>>>     this, so I hope someone who does will submit a PR.
>>>
>>>     Eric
>>>
>>>     ------------------------------------------------------------------------
>>
>>
>>
>>
>> -- 
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> Institute for Computational Engineering Sciences
>> 201 E. 24th St.
>> Stop C0200
>> The University of Texas at Austin
>> Austin, TX 78712-1229
>> Jeff Whitaker <mailto:js...@fa...>
>> July 6, 2013 10:04 AM
>>> Damon McDougall <mailto:dam...@gm...>
>>> July 6, 2013 9:32 AM
>>>
>>>
>>>
>>>     If I do a clean install of mpl master, and then of basemap, basemap
>>>     lands in dist-packages/mpl_toolkits, as it always has.  But now
>>>     it is
>>>     not found--I can't import it.  It seems that now the *real*
>>>     mpl_toolkits
>>>     is cleverly hidden inside an egg directory with a monstrous name,
>>>     leaving basemap orphaned in a directory with no __init__.py.  As a
>>>     workaround I can symlink it into the egg location.  I suspect
>>>     the real
>>>     solution will require basemap to use setuptools, correct?  I
>>>     don't know
>>>     how to do this, so I hope someone who does will submit a PR.
>>>
>>>
>>> Actually, using the new setuptools isn't adequate, I just tried it 
>>> locally on my machine and it still doesn't install itself into the 
>>> matplotlib egg.
>>>
>>> I think the proper solution here is to add basemap as an optional 
>>> dependency to matplotlib and have the user set a flag (off by 
>>> default) to pull basemap if it's desired
>>>
>>> Does that sound like a reasonable solution?
>>
>> What if a user decides later that he/she wants to install basemap?  
>> Then they would have to reinstall matplotlib? That doesn't sound 
>> reasonable to me.
>>
>> How about having matplotlib install a symlink to the egg location?
>>
>> Why the change to using setuptools by default in the first place?
>>
>> -Jeff
>>>
>>> P.S.  Note that the other mpl_toolkits are installed into the 
>>> correct place because they are shipped with matplotlib and installed 
>>> at the same time.  We could ship basemap with matplotlib too but 
>>> it's a rather large download.
>>>
>>> Best wishes,
>>> Damon
>>>
>>> -- 
>>> Damon McDougall
>>> http://www.damon-is-a-geek.com
>>> Institute for Computational Engineering Sciences
>>> 201 E. 24th St.
>>> Stop C0200
>>> The University of Texas at Austin
>>> Austin, TX 78712-1229
>>> Eric Firing <mailto:ef...@ha...>
>>> July 6, 2013 12:53 AM
>>> If I do a clean install of mpl master, and then of basemap, basemap 
>>> lands in dist-packages/mpl_toolkits, as it always has.  But now it 
>>> is not found--I can't import it.  It seems that now the *real* 
>>> mpl_toolkits is cleverly hidden inside an egg directory with a 
>>> monstrous name, leaving basemap orphaned in a directory with no 
>>> __init__.py.  As a workaround I can symlink it into the egg 
>>> location.  I suspect the real solution will require basemap to use 
>>> setuptools, correct?  I don't know how to do this, so I hope someone 
>>> who does will submit a PR.
>>>
>>> Eric
>>>
>>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> Damon McDougall <mailto:dam...@gm...>
>> July 6, 2013 9:32 AM
>>
>>
>>
>>     If I do a clean install of mpl master, and then of basemap, basemap
>>     lands in dist-packages/mpl_toolkits, as it always has.  But now it is
>>     not found--I can't import it.  It seems that now the *real*
>>     mpl_toolkits
>>     is cleverly hidden inside an egg directory with a monstrous name,
>>     leaving basemap orphaned in a directory with no __init__.py.  As a
>>     workaround I can symlink it into the egg location.  I suspect the
>>     real
>>     solution will require basemap to use setuptools, correct?  I
>>     don't know
>>     how to do this, so I hope someone who does will submit a PR.
>>
>>
>> Actually, using the new setuptools isn't adequate, I just tried it 
>> locally on my machine and it still doesn't install itself into the 
>> matplotlib egg.
>>
>> I think the proper solution here is to add basemap as an optional 
>> dependency to matplotlib and have the user set a flag (off by 
>> default) to pull basemap if it's desired.
>>
>> Does that sound like a reasonable solution?
>>
>> P.S.  Note that the other mpl_toolkits are installed into the correct 
>> place because they are shipped with matplotlib and installed at the 
>> same time.  We could ship basemap with matplotlib too but it's a 
>> rather large download.
>>
>> Best wishes,
>> Damon
>>
>> -- 
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> Institute for Computational Engineering Sciences
>> 201 E. 24th St.
>> Stop C0200
>> The University of Texas at Austin
>> Austin, TX 78712-1229
>> Eric Firing <mailto:ef...@ha...>
>> July 6, 2013 12:53 AM
>> If I do a clean install of mpl master, and then of basemap, basemap 
>> lands in dist-packages/mpl_toolkits, as it always has.  But now it is 
>> not found--I can't import it.  It seems that now the *real* 
>> mpl_toolkits is cleverly hidden inside an egg directory with a 
>> monstrous name, leaving basemap orphaned in a directory with no 
>> __init__.py.  As a workaround I can symlink it into the egg 
>> location.  I suspect the real solution will require basemap to use 
>> setuptools, correct?  I don't know how to do this, so I hope someone 
>> who does will submit a PR.
>>
>> Eric
>>
>> ------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel