[SciPy-User] Pylab - standard packages
Wed Sep 19 14:24:19 CDT 2012
On Wed, Sep 19, 2012 at 12:26 AM, Thomas Kluyver <email@example.com> wrote:
> 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?
I'd propose numpy >= 1.5.1, scipy >= 0.10.0, matplotlib >= 1.1. EPD,
Python(x,y) and AnacondaCE all fulfill those requirements. Sage likely does
too, but they don't list versions on their website.
> 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
> All your opinions are welcome,
> SciPy-User mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-User