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

[Philipp Rudiger]

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.

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.