[SciPy-User] Pylab - standard packages
Wed Sep 19 01:44:35 CDT 2012
On 9/18/2012 3:26 PM, Thomas Kluyver 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?
> 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,
the recent poll "Scientific Python packages: Popularity check" by Pierre
Raybaut  might be of interest.
In addition to EPD, Pythonxy, AnacondaCE, and Sage, also consider
WinPython  and ActivePython  as potential "Pylab compatible"
More information about the SciPy-User