[IPython-dev] rant: "%matplotlib inline"
Wes Turner
wes.turner at gmail.com
Sat Jul 4 14:42:41 EDT 2015
Because Python is a programming language with defined import semantics
and __builtins__.
Things that break this assumption are not Python, and so IMHO require
custom kernels or extra runtime configuration (a different *kernelspec*):
* CPython 2 (pylab)
* CPython 2 (matplotlib.inline = true)
* CPython 2 (sage)
So, to summarize: if the notebook expects a different locals() or globals()
or __builtins__, then it's a variant of CPython with *more convenient*
import configuration.
On Jul 3, 2015 11:53 PM, "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...
>
>
>>
>>
>>> The path forward is ti have fig object define a _repr_png_, the we don’t
>>> have to deal with %matpltlib inline
>>>
>>
>> No, that wouldn't cover at all a case like the 'notebook' backend, that
>> is the preferred one for matplotlib, that allows panning/zooming (and
>> hopefully one day all MPL events in the notebook):
>>
>>
>> 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 :)
>
> 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.
>
> When I'm writing code that I *know* is purely numerical, with no chance
> whatsoever of a namespace conflict, what exactly do I gain by having to
> write
>
> import numpy as np
> x = np.sin(np.pi*np.e)+np.log(z)
>
> instead of the vastly more readable, debuggable, comprehensible
>
> x = sin(pi*e) + log(z)
>
> ??? (and yes, I could do a lot of explicit single-function imports, but
> that gets old in a hurry when writing a lot of numerical code).
>
> For essentially one-off, matlab-style notebooks, I think that we need to
> be pragmatic and remember that ease of use, readability, ease of
> remembering what to write, are important. These are cases where people are
> not building large software engineering projects, and where getting
> something done *now* is what matters, so let's not get too dogmatic in
> berating them for using tools that actually help them accomplish something.
>
> So yes, I still use, and will continue to use %pylab quite a bit...
>
> 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.
>
> Cheers,
>
> f
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>
> _______________________________________________
> 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/20150704/e77c9aef/attachment.html>
More information about the IPython-dev
mailing list