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 -- http://mail.python.org/mailman/listinfo/python-list
