[Matrix-SIG] advocacy

[Scott M. Ransom]

I agree with almost everything you said.  And since I am a recent convert
from IDL to Python, it is certainly in my interest to see a project such
as this succeed.

There is quite a serious problem, however.  As you stated:

> Python has the promise to be *much* more, but it's not there yet.
> Mostly this is a problem with the add-ons, not the language itself.

and

> It's great to have the flexibility of modules, but to be successful
> among non-hacker scientists there has to be a "full version" with all
> the packages built, a well-organized structure, good docs, plotting
> capability, and support for all popular data formats.

This is the crux:  The module or add-on system is certainly the way to go
if you want stability, speed, and well tested code.  For example if you
want fast FFTs, FFTW is virtually the only solution for fast _and_
portable code.  And extremely well-tested, black-box style numerical
algotithms are common, freely available, and complete, on NetLib.

If we were to try and duplicate these efforts specifically for Python,
which a "full version" would probably require, and achieve even half of
the successes of the codes we were copying, we would have a _huge_
undertaking.

We either have to sacrifice some stability, speed, or bullet-proofness in
order to get a tightly integrated set of tools written specifically for
the "full version" of SciPy (I kinda like that name, BTW...).  Or we
figure out some way to embrace the module system and make it work.  A
couple possibilities for the second option:

1.  Have a maintainer for each major platform (Linux, AIX, Cray, HP Unix,
Sparc, Irix, DUX, Windows (yuk) etc) who patches, compiles, and links the
modules and then provides binary distributions of a working SciPy.  An
example of this would be NASA's binary distributions of FTOOLS which are
notoriously difficult to patch/compile/link.

2.  Develop a more robust package building system.  I know this is a
major topic of discussion for Python in general, but it seems
particularly applicable to our problem.

Whatever we decide (if anything)  I am certainly willing to help.  I have
switched to Python for the long-haul (and have managed to convince a few
of my collaborators to as well ;)

Scott Ransom


--
Scott M. Ransom
Phone:  (580) 536-7215             Address:  703 SW Chaucer Cir.
email:  ransom@cfa.harvard.edu               Lawton, OK  73505
PGP Fingerprint: D2 0E D0 10 CD 95 06 DA  EF 78 FE 2B CB 3A D3 53