[SciPy-User] Pylab - standard packages

Thomas Kluyver takowl@gmail....
Fri Sep 21 08:59:11 CDT 2012


On 21 September 2012 12:40, Almar Klein <a.klein@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.

> 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'. 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.

Again, I'll draw a parallel with R. R ships with a lightweight IDE,
and tutorials can assume you have that, but it hasn't stopped
alternatives like RStudio and Tinn-R gaining popularity. Once
programmers are comfortable with the language, they go looking for the
tools that suit them best. But I think we would be doing users a
disservice if introductory documentation couldn't assume any
particular interface.

Best wishes,
Thomas

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.


More information about the SciPy-User mailing list