Re: [matplotlib-devel] matplotlib build options

[Darren D. <dar...@co...>]

On Tuesday 13 November 2007 09:30:52 am John Hunter wrote:
> On Nov 13, 2007 8:01 AM, Darren Dale <dar...@co...> wrote:
> > On Monday 12 November 2007 06:39:28 pm Darren Dale wrote:
> > > On Monday 12 November 2007 05:52:55 pm John Hunter wrote:
> > > > On Nov 12, 2007 4:09 PM, Darren Dale <dar...@co...> wrote:
> > > > > I have been updating the logic in our setup.py and setupext.py
> > > > > files, so all of the build options are now exposed in setup.cfg.
> > > > > This should make it easier for anyone wishing to distribute
> > > > > matplotlib, like package managers. See setup.cfg.template for the
> > > > > details.
> > > >
> > > > I just did a clean build and it went through -- a good start!  I
> > > > tried enabling the new config with by setting NEWCONFIG = True in
> > > > __init__.py, and also enabled in setup.cfg
> >
> > I altered mplconfig to create a matplotlib.conf.template file, which gets
> > read and modified at build time like we do with matplotlibrc.template.
> > It's not as elegant as using the config package machinery to create the
> > default config file at build time, but I think this will serve our needs.
> > Devs still need to execute mplconfig.py when we make changes that would
> > affect the default config file.
> >
> > I also updated the selection of the default backend at build time:
> >
> > SVG -> Agg -> TkAgg -> WXAgg -> GTK -> GTKAagg -> selection in setup.cfg
>
> I'm not sure we need GTK in that pipeline, since its future status is
> in question and I think we'd rather have someone on tkagg or wxagg
> than plain vanilla gtk.

Done.

> I think in the autogen of matplotlib.conf, there are a few things you
> could do to make the file much more readable.
>
> * for the enumeration of options, print
>
>     # 'bilinear' or 'nearest' or 'bicubic' or 'spline16' or 'spline36' or
> 'hanni # ng' or 'hamming' or 'hermite' or 'kaiser' or 'quadric' or 'catrom'
> or 'gau # ssian' or 'bessel' or 'mitchell' or 'sinc' or 'lanczos' or
> 'blackman'
>
>     like
>
>     # bilinear | nearest | bicubic | spline16 ....

That is a good suggestion. However, most of the formatting is done under the 
hood, by the Traits package itself. It looks like the logic is spread out 
over traits code so it won't be easy to subclass and override the default 
behavior.

However, when we define our own trait handlers, like we do with BackendHandler 
and BoolHandler, we define an "info" method which controls the formatting. If 
we end up committing to using Traits, and we started adding more complex 
validation and notification, etc., I think that would be the time to add 
additional TraitHandlers to improve the formatting.

> * For floating point numbers, use a str converter rather than a repr
> converter, eg '%s'
>
>     In [4]: '%s'%0.1
>     Out[4]: '0.1'
>
>     In [5]: '%r'%0.1
>     Out[5]: '0.10000000000000001'

This is also dictated by Traits.

I'll have to think some more about formatting. Right now, its not obvious to 
me that there is a simple solution, aside from defining TraitHandlers.

> * I think your wrap algorithm is breaking in the middle of words.  You
> might look at cbook.wrap
>
>     In [15]: s = 'A regular expression used to determine the amount of
> space to remove.  It looks for the first sequence of spaces
> immediately following the first newline, or at the beginning of the
> string.'
>
>     In [16]: print cbook.wrap('', s, 76)
>     A regular expression used to determine the amount of space to remove. 
> It looks for the first sequence of spaces immediately following the first
> newline, or at the beginning of the string.

Thank you for noticing this, and for pointing out the solution in cbook. I 
updated tconfig in our repository and in ipython1.

Darren