[SciPy-User] Pylab - standard packages

[Nathaniel Smith]

On Fri, Sep 21, 2012 at 2:59 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 21 September 2012 12:40, Almar Klein <a.klein at science-applied.nl> wrote:
>> My main objection it that any chosen interface should not be implied as
>> *the* interface. For instance, Python(x,y) should still be pylab compliant
>> even though it uses Spyder as an interface. I suppose it's not hard for
>> Python(x,y) to include the IPython executable in the distribution. (As
>> opposed to integrating an IPython kernel with Spyder, which is obviosuly
>> much harder.)
>
> Of course, distributions would still be able to ship more than one
> interface, and write their own documentation pointing people towards
> Spyder, for example. But a Pylab tutorial might say e.g. "go to a
> terminal and start 'ipython notebook'", and we'd want that to work for
> anyone who had installed a pylab distribution.

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.

>> Further, you made a point about being able to share richer code documents
>> specific to the chosen interface. I strongly think that we should make
>> sharing code independent of the interface. Of course, withing a specific
>> user group, users are free to use specific formats, my point is that it
>> should not be encouraged from pylab.
>
> There is a desire to store data besides raw code, and the community is
> already starting to pick up ipynb files for that. I'm not sure about
> encouraging it, but I think the standard should enable people to
> exchange those files, at least.
>
> Nathaniel:
>> - A "pylab shell"
>
> 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)".

> If we do that, most distributions will ship IPython, and
> users of the odd one that doesn't will be stuck unable to use features
> everyone else has, and documentation might assume they have.
>
> Another argument for specifying IPython is that all the distributions
> we've discussed so far already ship it. Only Python(x,y) has an old
> version, but we're working on that. EPD (inc EPD Free), Anaconda,
> Sage, QSnake and WinPython all seem to have a more recent version. It
> is a de facto standard for scientific Python distributions. I see this
> as a push to formalise the de facto standards, the packages that we
> all know about, so newcomers don't need to hunt these out themselves.

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 :-).) So I think we'll get more
bang-for-buck if we focus on the former right now.

> Again, I'll draw a parallel with R. R ships with a lightweight IDE,
> and tutorials can assume you have that,

That lightweight IDE doesn't exist on Linux (I just run R in the
terminal), and in fact I never knew it existed until after I'd been
using R for some years. It's not actually mentioned in any tutorials I
ever read. I don't think I'm a particularly representative data point,
but it's a data point :-).

> 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 :-).

-n