New Python User Question about Python.

[Skip Montanaro]

    >> Exactly *why* there is relatively little interest in improving the
    >> speed of raw Python.  We all realize a more effective way to gain
    >> speed improvements is to profile and then recode as a C extension if
    >> (and only if) absolutely necessary.

    Chris> I think this explains the disconnect I see between user's and
    Chris> developer's (of Python) interest in speed optimization: A person
    Chris> qualified to work on the Python interpreter can whip up a quick C
    Chris> extension to speed up the bottleneck. 

Even though it's easier for a more experienced Python/C programmer to write
an extension, they are still not nearly as trivial to write as the
equivalent Python code, so there is still a subtantial barrier to clear.

    Chris> A user like myself who is a C novice, needs to put a whole lot of
    Chris> time into that same C extension. If I could compile some Python
    Chris> (perhaps with a few static type declarations or something) I'd be
    Chris> a whole lot more productive!!

One thing that everyone needs to remember is that optimizing any language is
extremely hard.  Sprinkling a few static type declarations into your Python
code isn't going to help much either.  Tim Peters spent a huge chunk of his
professional career as a compiler/optimization expert.  He's been working in
and around Python for about 10 years now, but he hasn't produced an
optimizing compiler for Python yet.  (I keep waiting...)  I think there are
(at least) two reasons: it's hard, and it's time-consuming.  Perhaps if we
all scraped together our nickels and dimes and sent them to PythonLabs
they'd be able to hire another person to do Tim's current job so he could
spend the next year on such a project.

    Chris> I had high hopes for the Py2C project, it seems like it had a LOT
    Chris> of potential for allowing this, but it seems to be stalled out

There is a fundamental problem with Py2C: In many cases it gets you about a
2X speedup but generates huge object files.  It more-or-less unrolls the
interpreter's main loop.  Also, since it operates at compile-time it can't
tell what functions should be converted to C and what ones aren't worth the
effort.  A runtime-based system could observe what functions are consuming
the bulk of the time and just translate them.

    Chris> In short: yes, speed matters, and Python could be a far more
    Chris> general purpose language than it is if the speed issue were
    Chris> addressed as succesfully as it has been for LISP.

Lisp had a 30-35 year head start on Python and even today probably has a
developer pool that is much larger than Python's.  Also, it's a bit unfair
to compare Python's performance with commercial offerings.  Again, there are
only so many people around who do this stuff, they only have so much time,
and they get paid well to do what they do.

-- 
Skip Montanaro (skip at pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/