<br><br><div class="gmail_quote">On Sun, Jun 3, 2012 at 7:08 PM, Fernando Perez <span dir="ltr">&lt;<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Sun, Jun 3, 2012 at 4:35 PM, Brian Granger &lt;<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>&gt; wrote:<br>
&gt; Doing so will add 1) docuemenation and 2) typing.  Putting things into<br>
&gt; dicts removes many of the benefits of our config system.<br></div></blockquote><div><br></div><div>I definitely disagree that we should expose *all* of the little tweaks we make for the inline backend defaults,</div>

<div>but maybe figsize and/or dpi.</div><div><br></div><div>Remember, the RC only exists because the matplotlib default config isn&#39;t quite appropriate, so we tweak it.</div><div>If any of our overrides aren&#39;t right for you, you might as well ignore the rest, because the margin / font</div>

<div>tweaks we make are probably irrelevant if you change the figure size and/or dpi.</div><div><br></div><div>Also, it should be possible to uncomment the existing InlineBackend.rc line for a no-op starting position,</div>

<div>which mitigates the issue (though on checking, I see that InlineBackend is not included in the generated</div><div>config files, which I will get on now.</div><div><br></div><div>-MinRK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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