Python advocacy in scientific computation

[Terry Reedy]

"Magnus Lycka" <lycka at carmen.se> wrote in message 
news:duh1b9$fvq$1 at wake.carmen.se...
> It seems the Python attitude to performance has largely been:
> Let Python take care of development speed, and let Moore's law
> and the hardware manufacturers take care of execution speed.

I think this is pretty fair, and yet .... the core Python interpreter has 
perhaps doubled in speed (hardware held constant) since some years ago. 
And new builtins like enumerate speed up code that needs to enumerate 
sequence items (which is not uncommon).  And class sets.Set is rewritten in 
C as builtin type set primarily for speed.

It is certainly true that Guido regards continued correct performance of 
the interperter to be more important that greater speed.  Ditto for Python 
programs.

> it seems now, increases in processing speed the coming years
> will largely be through parallell thread. If Python can't utilize
> that well, we have a real problem.

I believe it is Guido's current view, perhaps Google's collective view, and 
a general *nix view that such increases can just as well come thru parallel 
processes.  I believe one can run separate Python processes on separate 
cores just as well as one can run separate processes on separate chips or 
separate machines.  Your view has also been presented and discussed on the 
pydev list.  (But I am not one for thread versus process debate.)

> At
> least if writing threaded applications becomes less error prone
> in competing languages, this might well be the weak point of Python
> in the future.

Queue.Queue was added to help people write correct threaded programs.

> I hope to see some clever solution to this from the Python developers.

A Python developer is one who helps develop Python.  Threading improvements 
will have to come from those who want it enough to contribute to the 
effort.  (There have been some already.)

Terry Jan Reedy