Willem Broekema wrote:
It might have gotten a bit better, but the central message still
stands: Python has made design choices that make efficient compilation
hard.
OK, let me try this again. My assertion is that with some combination of
JITting,
reorganization of the Python runtime, and optional static declarations, Python
can be made acceptably fast,
That does not contradict that, had other language design choices been
made, it could be much easier to get better performance. Python may in
general be about as dynamic as Common Lisp from a _user_ perspective,
but from an implementator's point of view Python is harder to make it
run efficiently.
I think you are right about the design choices. The reason for those
design choices is that Guido intended from the beginning that Python
implementations be part of open computational systems, and not islands
to themselves like Smalltalk and some Lisps. While the public CPython
C-API is *not* part of the Python language, Python was and has been
designed with the knowledge that there *would be* such an interface, and
that speed-critical code would be written in C or Fortran, or that
Python programs would interface with and use such code already written.
So: Python the language was designed for human readability, with the
knowledge that CPython the implementation (originally and still today
just called python.exe) would exist in a world where intensive
computation could be pushed onto C or Fortan when necessary.
So: to talk about the 'speed of Python', one should talk about the speed
of human reading and writing. On this score, Python, I believe, beats
most other algorithm languages, as intended. It certainly does for me.
To talk about the speed of CPython, one must, to be fair, talk about the
speed of CPython + extensions compiled to native code.
In the scale of human readability, I believe Google go is a step
backwards from Python.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
