where are the program that are written in python?

[Terry Reedy]

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 believe Raymond wrote each itertool (or at least most) in Python 
first, then rewrote each in C for speed, since they are intented to be 
repeatedly used components of other Python programs. He is not 'doubting 
Python's speed', just being realistic.

 > Look at Mercurial vs. SVN;

Neither are being sold, as far as I know.

> Mercurial is written in Python while SVN in C.
 > Mercurial beats SVN in speed by several orders
> of magnitude.

Because, as I said, and as you explain further, Python favors programmer 
speed, including speed of testing new algorithms, over raw execution 
speed of current algorithms. (Current) speed is (also) easier to test 
than improvability and hence possible speed improvements.
>
> One of Mercurial's design goal was to be faster than SVN, if the
> programmers have naively believed that choice of language would matter
> to program's speed, they'd choose to write Mercurial in assembly instead
> (the same argument applies to Git, written in shell scripts).
>
> Now, you may think this is an unfair comparison, since Mercurial is hype
> and new, SVN is antiquated and old. But it shows that in real-life, the
> language being inherently slow often dosn't matter. What matters more
> are the choice of data structure and algorithm, I/O speed, network
> latency, and development speed.

If and when mercurial deveopment slows down, some of its developers 
might consider whether any of the utility functions written in Python 
might usefully be rewritten in C. One of the intentional virtues of 
Python is that one can transparently convert part or all of a module 
*without changing* the import and use of the module.

Terry Jan Reedy