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
--
http://mail.python.org/mailman/listinfo/python-list
