[IPython-dev] Small config puzzle

MinRK benjaminrk@gmail....
Sun Jun 3 21:55:19 CDT 2012


On Sun, Jun 3, 2012 at 7:08 PM, Fernando Perez <fperez.net@gmail.com> wrote:

> On Sun, Jun 3, 2012 at 4:35 PM, Brian Granger <ellisonbg@gmail.com> wrote:
> > Doing so will add 1) docuemenation and 2) typing.  Putting things into
> > dicts removes many of the benefits of our config system.
>

I definitely disagree that we should expose *all* of the little tweaks we
make for the inline backend defaults,
but maybe figsize and/or dpi.

Remember, the RC only exists because the matplotlib default config isn't
quite appropriate, so we tweak it.
If any of our overrides aren't right for you, you might as well ignore the
rest, because the margin / font
tweaks we make are probably irrelevant if you change the figure size and/or
dpi.

Also, it should be possible to uncomment the existing InlineBackend.rc line
for a no-op starting position,
which mitigates the issue (though on checking, I see that InlineBackend is
not included in the generated
config files, which I will get on now.

-MinRK


>
> Though keep in mind that in this case we're forwarding data to
> matplotlib, so I don't think we should be in the business of
> documenting each of those keys from their docs.  For the entire rc
> object we can say 'Dict of options for matplotlib', but if we handle
> each field by hand, we'd be essentially duplicating the matplotlib
> docs and type info (and possibly going out of sync with them).
>
> Plus, it then means we have to manually add code to sync each of these
> values with the corresponding key in the mpl rc structure.  We'll have
> say
>
> c.InlineBackend.rc_savefig_dpi = 99
>
> and then will need to manually update
>
> plt.rcParams['savefig.dpi'] = ...rc_savefig_dpi
>
> once for each field.  Right now we simply do plt.rcParams.update(c.rc)
> and we're done.
>
> Granted, since we're only handling a few keys this way the boilerplate
> isn't too terrible, but I wouldn't want to write such code for all the
> matplotlib options :)
>
> The alternative is to tell users to first initialize the value with
> the dict/list by importing the class object from our own code:
>
> from IPython.core... import InlineBackend
>
> c.InlineBackend.rc = InlineBackend.rc.copy()
> c.InlineBackend.rc['foo'] = 'bar'
>
>
> Each solution has some drawbacks, I'm not sure right now which are worse...
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20120603/f02a8433/attachment.html 


More information about the IPython-dev mailing list