Python compilers?

[Svein Ove Aas]

Heiko Wundram wrote:

> Am Dienstag, 18. Mai 2004 13:41 schrieb Jacek Generowicz:
>> Native compilers for other languages just as dynamic as Python
>> exist. These compilers manage to achieve very significant speed
>> increases[*].
> 
> You are again refering to LISP as an example of a dynamic language which
> when compiled gives huge speed increases. This is true in some respect,
> in others it isn't. LISP has the advantage that type-inference may be
> used throughout the program to create one version of each function,
> which can then be compiled. Of course it still has to call into runtime
> functions to do the high-level work, but there is actually only one
> representation of each finished LISP program, and only one set and one
> proper order of runtime-functions to call.
> 
> In Python this isn't true. Python, instead of LISP, is "completely"
> dynamic, meaning that it's pretty impossible to do type-inference for
> each function that is called (even checking types isn't possible). E.g.
> how do you expect type-inference to work with the pickle module? string
> -> something/Error would be the best description what pickle does. For
> the function which calls pickle, do you want to create versions for each
> possible output of Pickle? Which outputs of Pickle are possible?
> (depends on the loaded modules, which can be loaded at runtime) There is
> no (sane) way to create machine-code which calls into the appropriate
> (low-level) Python-runtime functions (such as Py_List*, Py_Dict*, etc.)
> for such a method, at least not at compile-time.

I suppose that's true; pickle is an exception, and the compiler would pick
that up. (The Lisp (print) function is approximately equivalent, at least
when *print-readably* is true.)

What you're claiming, though, is that it's possible to write Python code
that can't easily be translated to equivalent Lisp code. Can you give an
example?