Why not a Python compiler?

[Hrvoje Niksic]

Ryszard Szopa <ryszard.szopa at gmail.com> writes:

>> The main determinant of Python's performance isn't the interpreter
>> overhead, but the amount of work that must be done at run-time and
>> cannot be moved to compile-time or optimized away.
>
> Well, I am still not convinced that Python is intrinsically
> un-compilable :-).

It's not.  My point is that it's very hard to optimize if your goal is
to implement Python as currently defined.

> Some optimizations that are nowadays done by hand probably could be
> abstracted. Think assigning a method to a local variable before using
> it in a loop...

That's an example of what I'm talking about: it is simply not correct
to cache methods in general.  If you think changing classes is a
no-no, remember that function objects can be and do get added to an
individual instance's __dict__.  Of course, your compiler could
support a declaration that disables the optimization for code that
really needs to do it, but then you're no longer compatible with
Python.  (And by "Python" I don't mean just CPython, but the core
language as defined by the language reference and implemented in
CPython, Jython, and IronPython.)

> Anyway, I won't be very surprised if in a couple of years your
> average c.l.py troll is going to be asking "So I heard that Python
> is an interpreted only language, how can it be any good?", and you
> will be explaining for the thousandth time: "Since version 4.2
> Python has a fast native code compiler, so...". ;-)

I'll be very happy to be proven wrong in that respect.  :-)