[SciPy-User] Pylab - standard packages

Thomas Kluyver takowl@gmail....
Fri Sep 21 10:50:40 CDT 2012


On 21 September 2012 15:39, Nathaniel Smith <njs@pobox.com> wrote:
> I think by definition, a "pylab tutorial" would have to be one that is
> aimed at a somewhat amorphous set of configurations (different OSes,
> distributions, etc.), and has some other goal beyond describing how to
> start up a Python REPL. Being able to say "start up a Pylab shell and
> ..." will already get us quite a long way, so long as all "pylab
> shells" are equivalent in the ways that matter for the tutorial. Being
> able to plot matters much more than where exactly in the UI those plot
> windows end up located.

If it was as simple as where plot windows turned up, yes. But there
are a whole host of issues from starting the interface to syntax like
"foo?" that differ. They might seem trivial, but they're all things
that will confuse new users going through a tutorial. So I think a
standard interface is important.

>> I'd rather not say 'it has to work x much like IPython, but it needn't
>> be IPython'.
>
> Indeed, that'd be a terrible idea. I mean "pylab shell" as "the shell
> you get by default when using a pylab-oriented environment (which will
> be implemented by ipython, and also satisfy these other potential
> requirements)".

But what your requirements describe is a subset of IPython's
functionality, and I expect we'd extend that subset - the 'foo?'
syntax I mentioned is extremely useful, for instance. Rather than
people reimplementing that, why not simply push the code we've already
written for the purpose, i.e. IPython?

> Right. And IPython-the-REPL is a de facto standard, but IPython
> notebooks are not. (At least not yet. Obviously with your IPython hat
> on you're working on changing that :-).)

I'll agree that the notebook isn't quite a de facto standard, but it
has gained a lot of traction in a short time. At Euroscipy 2011,
Fernando demoed the first cut of the notebook, which had been merged
days earlier. At Euroscipy 2012, we had several demonstrations given
from notebooks. So even if the notebook isn't in the first version of
the standard, I hope it will get a place in the future.

Is this a position we can find consensus on? Pylab distributions
should include IPython, but need not be able to run IPython notebook,
i.e. pyzmq and tornado would not be required packages.

>> P.S. Nathaniel: you describe trying to set conventions for how to test
>> packages or find documentation, not to mention installing packages. I
>> agree with all of that, but I'd like to put it under 'battles to fight
>> another day'. If we're going to do anything, we can't try to do
>> everything.
>
> Really I'm trying to work toward consensus on what "pylab" should mean
> and what's in principle in scope. If we agree that these are the kinds
> of things that pylab should stand for, then they can go on the todo
> list until someone actually gets around to them. Anyway, volunteer
> effort isn't a conserved quantity. Having a long todo list can
> actually increase your chances of helpers showing up :-).

I think those things are out of scope for 'Pylab', in that they
shouldn't be part of the standard. But in doing this sort of
integration, we will highlight those inconsistencies, and I hope this
community will play a key role in fixing them. So by all means put
them on the to do list, but let's not get distracted by them at the
moment.

Travis:
> But, already in IPython the %pylab command (or ipython --pylab) creates a workspace where at least numpy
> names and matplotlib plotting names are available --- this should be resolved so that either there are two
> approaches clearly labeled or just one.

To clarify the background, installing matplotlib also installs a
'pylab' module which imports a number of names from matplotlib and
numpy. IPython's pylab mode then does 'from pylab import *'. One of my
secondary goals for this effort is to disentangle that namespace from
being part of matplotlib, but that's for another day.

Thanks,
Thomas


More information about the SciPy-User mailing list