"Magnus Lycka" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 -- http://mail.python.org/mailman/listinfo/python-list
