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

Nathan Goldbaum nathan12343 at gmail.com
Mon Jul 6 11:58:02 EDT 2015


On Sun, Jul 5, 2015 at 2:23 PM, Philipp Rudiger <P.Rudiger at ed.ac.uk> wrote:

> For a different perspective there are third-party projects that offer
> alternative functionality to "%matplotlib inline" and "%pylab inline".
> In HoloViews (holoviews.org) we supply an IPython extension that relies
> on matplotlib inline not being enabled by default.
>
> We use matplotlib internally to generate display output, handling the
> display part ourselves (via display formatters). When %matplotlib inline
> is enabled these two systems can interact in bad ways. I suspect we are
> not the only project that might want to use matplotlib internally to
> generate custom display output.
>
> We also feel that being explicit is usually less confusing and allows
> more flexibility. However if you decide to make it the default there
> should be a safe and reliable way to unload matplotlib inline
> dynamically (maybe there is already?).
>
>  From an outside perspective it seems like the repr_x methods already
> provide a general system for automatically generating appropriate
> display output and that this could be supported at the matplotlib level.
>

I agree with this -- we do the same thing in yt. yt plots "just work" in
the notebook without
%matplotlib inline since the plot objects have _repr_png_ and _repr_html_
defined.


>
> On 05/07/15 21:32, Brian Granger wrote:
> > 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
> >>
> >
> >
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150706/00bcac48/attachment.html>


More information about the IPython-dev mailing list