Python advocacy in scientific computation

[Michael Tobis]

1) indentation:

I claim that this is a trivial matter. Indentation is enforced, but if
you want to end all your blocks with #end, feel free.

Or write a preprocessor to go from your preferred block style to
python's

2) self.something tedious to look at.

Again, you can somewhat work around this if you like. Just use "s" or
"_" instead of "self".

3) missing

4) multithreading and parallel execution impossible

This is simply false, though admittedly the MPI libraries need a little
work. Mike Steder of our group is likely to release an alternative. A
good way to think of Python is as a powerful extension to C. So using
MPI from Python just amounts to setting up a communicator in C and
wrapping the MPI calls.

As for less tightly coupled threads on a single processor, Python is
adept at it. I think the issues with multiple processors are much more
those of a server farm than those of a computational cluster.

We have been encountering no fundamental difficulty in cluster programs
using Python.

5) "I don't like numpy's array slicing" ?

this is unclear. It is somewhat different form Matlab's, but much more
powerful.

1) pass by reference

Python names are all references. The model is a little peculiar to
Fortran and C people, but rather similar to the Java model.

2) matplotlib

A correct install can be difficult, but once it works it rocks. ipython
(a.k.a. pylab) is also a very nice work environment.

3D plots remain unavailable at present.

3) speed

Speed matters less in Python than in other languages because Python
plays so well with others. For many applications, NumPy is fine.
Otherwise write your own C or C++ or F77; building the Python bindings
is trivial. (F9* is problematic, though in fact we do some calling of
F90 from Python using the Babel toolkit)

4) useful libraries

yes. for your svd example see Hinsen's Scientific package. In general,
Python's claim of "batteries included" applies to scientific code.

mt