[SciPy-User] Pylab - standard packages
Wed Sep 19 05:21:03 CDT 2012
At first the idea of a "Pylab" standard appealed to me (it still does,
but with caveats, which see below). Like everyone, my lab has a
standard Python stack on all our machines, and it's a pretty long list.
It would be nice to cut it in half, and let someone else worry about the
integration issues. So I tried to make my list of what to include that
wasn't specific to my discipline.
...And I discovered that this idea is a wickedly slippery slope. While
I have my own reasons for choosing certain packages over others, the
community has organized to encourage lots of topical subpackages, from
broad-use packages like matplotlib to specialist things like astropy.
Even within an area, such as plotting, there are options, and
competition is critical to get great packages.
BUT if your package is in PylabTM and your competition isn't, you have a
*big* advantage. You'll get installed by every Linux distro, and the
computational Python distros will want to be in compliance as well, so
you'll show up there. Regardless of intent, if the community makes this
a standard and a distro does not follow it, it will look strange:
tutorials written to the Pylab standard will not work with that distro,
commonly shared code will not run in it without add-ons, etc. So,
distro maintainers will want to be in compliance if they can be. By
choosing among packages, Pylab will stifle competition, regardless of
our pure intent.
I still want there to be a Pylab, for selfish reasons cited above.
I can see a couple ways out, gotten to by asking, WHOSE NEEDS ARE WE
TRYING TO SERVE?
1. Make the set only include packages for which there is essentially no
competition. numpy+scipy+ipython+binary file formats? I think there is
consensus that Matplotlib is standard, but are we really ready to
formalize the "next-best" status of all other plotting packages? I
think we actually might be, but I don't think that's true for any other
package with serious competiton. So
numpy+matplotlib+scipy+ipython+binary file formats. I am edgy about
ipython, but let's face it, almost everyone uses it. The fact that it
contains some new material for which the competition hasn't been decided
(i.e., notebook and related features) is a complicating factor. We will
want to jam other packages in here, like cython and sympy. If we're
preserving competition, it will have serious holes. It will be unwieldy
for beginners (too big) and will require lots of add-ons for experienced
people and production use. DOES IT SERVE ANYONE? I don't think anyone
will like it.
2. Include *everything*, and don't make choices among competing
packages. DOES IT SERVE ANYONE? Maybe big labs with lots of disk
3. Define several levels of Pylab:
Level 1: Stuff needed for beginner tutorials, Numerics 101 classes, etc.
I think just numpy+matplotlib+scipy+ipython+binary file formats.
Declare that beginner tutorials stick to this set to be Pylab-approved
tutorials and get a link from the Pylab-level-1 page. The tutorials
would also have to comply with coding standards like "import numpy as
np", etc. We may also declare that compliant tutorials will not use
certain features of Ipython. I see things like common scientific binary
file formats as very important, as anyone switching from another
language will have data. DOES IT SERVE ANYONE? Yes, beginners (and
Level 2: The above plus things like cython, symbolic math, serious
financial functions, unit conversions, serious stats, C, C++, FORTRAN,
etc., but not selecting any package where there is still competition.
Yes, this will leave holes, but people operating at this level are
capable of making choices, and distros are welcome to fill in. DOES IT
SERVE ANYONE? It's a good, smallish base for technical users to build
Level 3: The above plus ALL stable, general-purpose packages that meet a
certain standard, including different competitive variants for the same
task. DOES IT SERVE ANYONE? Big installations with one specialty.
Level 4: The above plus specialist packages like astropy. DOES IT SERVE
ANYONE? Big installations with many specialties.
I like option 3. In all my thinking on this problem, I could not find a
minimal set that was useful to advanced users and didn't stifle
competition. So, instead we have a minimal set that isn't geared toward
advanced users, and that encourages consistency across tutorials. Then
we have levels of increasing inclusiveness, size, and utility to
advanced users, none of which stifles competition.
Most importantly, the "in" list for any level certifies that all
included packages are stable, actively maintained, well documented, and
do not fight with the rest of the packages.
I think that requiring functionality rather than specific packages is
not very useful. What utility is there in saying you have an IDE, a
syntax-highlighting editor, etc. without specifying which one? I can
see saying "a C compiler", though. Perhaps saying "one or more of ..."
and listing specific IDEs/editors/etc. would be ok. That at least
provides the service of certifying that those listed actually work well
with the stack.
Finally, I think that there should be installers. Certifying the work
of others is nice, but the real benefit will be in actually having
something to install. But if there are two entities, one that certifies
and one that makes an installer for each defined Pylab level, I'm fine
with that. I'd just hate to see a defined Pylab level for which no pure
installer (i.e., no installer for just those packages) is available.
Thanks, and sorry for the length.
Prof. Joseph Harrington
Planetary Sciences Group
Department of Physics
4000 Central Florida Blvd.
University of Central Florida
Orlando, FL 32816-2385
... On sabbatical at: ...
Max-Planck-Institut für Astronomie
More information about the SciPy-User