Scientific Libraries in Python

Horatio Davis horatio at
Sun Nov 25 13:22:35 CET 2001


On Thu, 15 Nov 2001, Fernando [ISO-8859-1] Pérez wrote:

> I'd like to draft a rough map of the problem landscape.

Having read this excellent mud map of the problem space, and the
followups, I'd like to add my my $0.01 (would be $0.02 but the exchange
rate on the Aussie dollar is fairly embarrassing right now).

In order of priority, these are the tools I want in a single codebase:

SciPy (Enthought) - general code library - BSD license
ScientificPython (Hinsen) - general code library - Python license
MayaVi (Ramachandra) - 3D visualization over VTK - GPL
PyGSL (Gabriel et al) - Python bindings for GSL - GPL
SciGraphica (Feiguin et al) - 2D graphing package over GTK+ - GPL
mxNumber (Lemburg) - Python bindings for GMP - OSI/Python license

SciGraphica looks to be shaping up as the MayaVi of the 2D plotting
domain. It is apparently written in C and embeds Python, rather than the
other way around, but mention is made of command-prompt interaction with
plots and worksheets, which raises the possibility of exposing it as a
library in the style of scipy.plt.

mxNumber is part of the excellent mx-Extensions packages. This project is
definitely alive and well, and that makes it the best choice for a GMP

The list of scientific packages above requires at least the libraries:

ATLAS (Whaley & Petitet) - self-optimizing CBLAS - BSD license
VTK (Martin et al) - 3D visualization on GTK - personal copyright
GSL (Galassi et al) - mathematical (non-Numeric) library - GPL
GNU MP (Granlund et al) - arbitrary precision arithmetic library - GPL
Numeric (Dubois et al) - efficient numerical array type - OSI
mxTools (Lemburg) - set of utility modules - OSI/Python
GTK+ and GTKExtra - GIMP toolkit and extra widget set - LGPL,

This list is not complete, but I've included it as a rough draft of what
would be in Chris Barker's "Scientific Python Distribution". They neither
need nor want to be integrated into a Grand Unified Scientific Library,
but they would have to be packaged in such a Distribution. Most of these
are just the underlying C libraries upon which the scientific Python
libraries are built. mxTools isn't, but it makes the list because of
mxNumber, and because the general functionality it provides is useful.

Numeric Python, of course, makes whichever list it feels like. (:

I've left it out of both lists because there's an announcement on the
NumPy home page that it is being reimplemented from scratch by Perry
Greenfield and company. This looks (to my untrained eye) like they're
going ahead with the Numeric 2 proposed in PEP 209, and are going for
inclusion in the Python standard library. Implications for the unified
scientific library are left as an exercise for the reader. Could we have
comments from anybody on that project team?

For a sane naming structure, I still reckon a deep package structure
rooted at Scientific is the ideal, but again, that's a secondary issue.

Now... licensing. While the top two projects are both less...restrictive,
I reluctantly have to concede that these lists have an awful lot of GPL
code that would be difficult or impossible to do without. The eventual
license, therefore, looks like GPL or (if we're lucky) LGPL. I can even
live with that if it'll get me a coherent scientific library, but others
might have a different viewpoint. What would those viewpoints be?

hoping-he's-not-an-unwitting-pawn-of-the-PSU'ly yours,


More information about the Python-list mailing list