[SciPy-User] Pylab - standard packages

Thomas Kluyver takowl@gmail....
Tue Sep 18 17:26:06 CDT 2012


Hi again,

It now looks like we're going to use Pylab as the name for the 'scipy
stack'. Now I want to turn to the question of what it should include.
The idea is that Python distributions can call themselves Pylab
compliant if they provide at least a defined set of packages. Also, I
hope that it will become a metapackage in Linux distributions, so that
users can 'apt-get install pylab' or similar

As a minimum, I assume we should require Python, Numpy, Scipy and
Matplotlib. Does anyone disagree?

I also think we should specify minimum versions. The standard itself
will be versioned, so we can raise these over time. For Python, I
intend the requirement to be 2.x >= 2.6 or 3.x >= 3.2. What are
sensible minimum versions of Numpy, Scipy and Matplotlib?

Should the standard include an interface? IPython, a more traditional
IDE, or both? On the one hand, specifying a standard interface means
users can share experience better, and exchange richer files, like
IPython notebooks or IDE project structures. Matlab, for instance,
wins praise for including a powerful IDE by default. On the other
hand, we've got several interesting UI efforts still taking shape -
IPython notebooks, Spyder, IEP - and declaring one standard would make
the alternatives less visible. I'm honestly torn on this - I can see
good arguments for and against.

Other scientific packages we might consider include pandas (which
provides functionality similar to core parts of R), Sympy, Cython,
various scikits projects, h5py, and doubtless many others I haven't
thought of. We could also specify general purpose Python packages such
as requests, or a GUI toolkit.

On the NumFOCUS list, Chris Kees raised the idea that there could be
two or more levels of packages, e.g. 'core' and 'recommended'. I don't
think we should add that kind of complexity in the first version, but
keep in mind that we could differentiate it later.

Finally, I mean the standard to specify that the distribution must
offer a way of installing arbitrary extra Python packages into it, so
the standard shouldn't try to include everything you might need for
scientific computing. The aim is to offer a key set of tools so you
can get started without having to add things. "Get started with what?"
is the key question we have to answer. In my field, for example,
statistical tests are fundamental, while symbolic maths is hardly
used.

All your opinions are welcome,

Thomas


More information about the SciPy-User mailing list