>Re speed, if i recall correctly, a few of the reports at the last VHLL
>conference did not attribute that as a relative failing of python.
>Python was rated, re speed, about comparable with perl, with scheme
>coming out significantly, but not extremely, faster, and tcl coming
>out significantly *and* extremely slower.
Had to jump in on this point only. Python has a lot of indirection
and is *always* interpreted, which makes it sometimes slower vis-a-vis scheme
and Perl, I believe.
This is a non-issue for applications where it is worth the effort to
write a tiny little bit of C code whenever speed is a problem. Python
has a very nice and shockingly easy interface to C extensions (which
needs better documentation, unfortunately). Whenever I find a piece
of code slowing me down too much, I first make sure it's right in
Python and then "push" it to C and the results are very gratifying.
For example, if you want to do a lot of database-style index manipulations
maybe you can run faster with a scheme-only or a Perl-only
implementation versus a Python-only implementation (but I'd wager
it'd take you longer to write than using Python), but if you use my
(ahem) kjbuckets C extension, which defines a fast graph operators
for python, I believe you can come darn close to the speed you'd get
from spending a semi-infinite amount of time implementing your app
directly in C. [Don't even think about TCL.]
The speed thing is also a non-issue if you need to get the thing
working yesterday. I'm still amazed at how much of my Python code
works perfectly on the first go. This is the first time I've
had this experience (and I've seen 'em come and go).
That said, I believe python still needs a larger suite of
C-implemented ADT's and better collection-at-a-time operators. IE, Why
can we convert a dict to a list with D.items(), but there is no
C-level inverse? [Actually, I have a student working on this one,
among others. :)] Why not a matrix type also? Also, even a fairly
brain-dead Py2C converter wouldn't hurt (and really wouldn't be that
hard if kept simple). I understand some basic interpreter
optimizations are in the works as well... So much time, so little to
do -- scratch that! Reverse it!
Aaron Watters
Department of Computer and Information Sciences
New Jersey Institute of Technology
University Heights
Newark, NJ 07102
phone (201)596-2666
fax (201)596-5777
home phone (908)545-3367
email: aaron@vienna.njit.edu
===
If you never ask your self "why am I doing this?" you may get to the
end of your life and ask "why did I do that?" However if you always
ask yourself "should I really do that?" you'll almost certainly get to
the end of your life and ask "why didn't I do anything?"