where are the program that are written in python?

[Lie Ryan]

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.