On 05/23/10 04:49, Terry Reedy wrote: > On 5/21/2010 11:03 PM, Lie Ryan wrote: >> On 05/22/10 04:47, Terry Reedy wrote: >>> On 5/21/2010 6:21 AM, Deep_Feelings wrote: >>>> python is not a new programming language ,it has been there for the >>>> last .... 15+ years or so ? right ? >>>> >>>> however by having a look at this page >>>> http://wiki.python.org/moin/Applications >>>> i could not see many programs written in python (i will be interested >>>> more in COMMERCIAL programs written in python ). and to be honest ,i >>> >>> There are two kinds of 'commercial' programs. >>> 1. The vast majority are proprietary programs kept within a company for >>> its own use. As long as these work as intended, they are mostly >>> invisible to the outside world. >>> 2. Programs sold to anyone who wants them. >>> >>> Python trades programmer speed for execution speed. If a successful >>> Python program is going to be run millions of times, it makes economic >>> sense to convert time-hogging parts to (for instance) C. In fact, this >>> is a consideration in deciding what functions should be builtin and >>> which stdlib modules are written or rewritten in C. >>> >>> Programs being sold tend to be compared to competitors on speed with >>> perhaps more weight than they rationally should. Speed is easier to >>> measure than, for instance, lack of bugs. >> >> doubting python's speed? > > The is a somewhat bizarre response to me. I have been promoting Python > for about 13 years, since I dubbed it 'executable pseudocode', which is > to say, easy to write, read, understand, and improve. I am also a > realist. Any fixed (C)Python program can be sped up, at least a bit, and > possibly more, by recoding in C. At minimum, the bytecodes can be > replaced by the C code and C-API calls that they get normally get > translated into. Ints can be unboxed. Etcetera. This tend to freeze a > program, which is fine when development is finished.
I'm not claiming Python is faster than C, but I'm just being a realists, when I say that in real life 9 out of 10 writing a program in a slow language doesn't really matter to actual program speed. I used Mercurial as an example where the developers choose an initially irrational decision of using a slow language (python) to beat the speed of a fast language (C). Of course, you can always point out the 1 case out of 10. In this cases, python can still cope with C extension, Psyco, Numpy-and-friends, Cython, or even dumping python and using full C all the way. But the point still hold, that in real life, often the language's raw speed doesn't really limit the program's speed. -- http://mail.python.org/mailman/listinfo/python-list
