[IPython-dev] rant: "%matplotlib inline"

[Brian Granger]

To clarify my thinking.

I think that users should not have to run "%matplotlib inline" to get
the inline backend to work in the notebook. I think we should make it
"just work" and think we should favor practicality on this one rather
than purity.

On Sat, Jul 4, 2015 at 12:57 PM, Matthias Bussonnier
<bussonniermatthias at gmail.com> wrote:
>
> On Jul 3, 2015, at 21:53, Fernando Perez <fperez.net at gmail.com> wrote:
>
> On Fri, Jul 3, 2015 at 9:15 PM, Matthias Bussonnier
> <bussonniermatthias at gmail.com> wrote:
>>
>>
>>
>> Well, that would be a step-back from what we have been doing for the last
>> 2 release to remove knowlege of IPython in Jupyter.
>> Or, actually break one abstraction that kernel do not know what have
>> started them.
>> If we do one I would prefer the more general one.
>
>
> No, it's not IPython-specific, it would simply be recording in any kernel
> how they were started. That information could be useful in a variety of
> contexts...
>
>
> I would technically prefer that the request/response also carry a field of
> what kind of frontend make a request.
> That might allow finer grain behavior of kernel. Anyway, we agree on that,
> we just don’t use the same terms.
>
>> Well, also define _repr_html_ or _repr_js_ for notebook then.
>> The general message is to use our display_protocol the way it is design
>> for matplotlib too.
>>
>> Julia and R don’t need special activation and don’t have these issues, I
>> don’t see why we can’t figure
>> out how to do theses things.
>
>
> If we can find a cleaner solution with our display protocol, great!  Those
> ideas are certainly a lot more mature now than when we first hacked up the
> backend support in the early days of the qt console, and we also have a lot
> of real-world experience using it, teaching with it, etc.  It's a good time
> to take stock of that knowledge and update the toolchain...
>
> I see one or more PRs coming next week from Scipy :)
>
>
> Does that mean you are coming ?
>
>> PS: Booooo Pylab :-)
>
>
> Actually, I use it a lot, and I think it's a mistake to berate it: %pylab is
> exactly the right thing to do when you need to quickly have something that
> puts at your fingertips a bunch of numerical tools.
>
>
> Well, that was just teasing as the thread started with why not use pylab.
>
>
> So yes, I still use, and will continue to use %pylab quite a bit...
>
>
> I do too, but I think it should only be use by people the **know** what it
> does.
>
> We **still** get confused bug report of people telling us that `nbconvert to
> --python` should include
> all the import that IPython does at startup by default[1]. While it does
> not, people just use %pylab inline
> assuming it just set the matplotlib backend for the notebook.
>
> From the issue in [1]
>
>     [...] I just took existing tutorials and
>     such which almost always begin with *%pylab inline*. I'll have to
>     figure out which of the other imports I'll have to do explicitly in
>     the notebook.
>
>     IMHO all of the points you discussed are worth mentioning in some
>     highly visible place on the project website and/or documentation, to
>     save people the trouble of figuring these things out the hard way.
>
>
> So you you want to be accurate, if you have a response that tell user %pylab
> inline just make figures inline.
> you can either correct by :
>  - no, %matplotlib inline does it,
> or
> - no, %pylab inline does not only set up the inline backend, but it will
> also import a bunch of stuff from
>   many packages, and be careful it shadows some builtins (in particular sum
> and any) with the numpy one,
>   and  will make it more work to convert your notebook to .py files.
>
> Most of the time, the first answer is just the adapted one.
>
>
> Remember, readability counts and practicality beats purity...
>
> Don't forget to import this every now and then, it's always a good antidote
> against dogmatism.
>
>
> I do, I agree that %pylab is practical, however IMHO it is against the
> "Explicit is better than implicit".
>
> I also disagree that it helps with readability, for me it’s neutral for the
> subpart of %pylab I use.
>
> It also make me think that in the notebook, the text editing is flexible
> enough, the we could actually expand it to
> what it does.
>
> import numpy
> import matplotlib
> from matplotlib import pylab, mlab, pyplot
> np = numpy
> plt = pyplot
> from IPython.core.pylabtools import figsize, getfigs
> from pylab import *
> from numpy import *
>
> That would make it still “practical”, but explicit; and make it easier to
> export %pylab’ed notebook to python scripts.
> (and could also be used for %load).
>
> --
> M
>
>
>
>
> Cheers,
>
> f
>
>
>
> [1]: https://github.com/jupyter/nbconvert/issues/54
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com