A faster Python?, Python compiler, Dylan,...

[Jan Kybic]

The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.

SM>Have you tried weave?  It's part of SciPy.  From the SciPy front page:
>    Weave 0.2.1 Now Available: weave is a new package that provides tools
>    for including C/C++ code within Python code.  The weave.inline()
>    function executes C code directly within Python, weave.blitz()
>    translates Python Numeric expressions to C++ for fast execution...

Basically weave permits you to put both the C code and the Python code
into one file. Not bad, but you still have to write the code twice.
Useful for short C fragments, not long ones.

SG> Dubois dubbed this "steering your code". I do not have got much
> experience at this field (foreign functions). But why do you think that
> steering code is in the long run not the panacea? 

This is the first time I hear this  expression ('steering your code').
My major complaint is that you need to write the same code twice -
first in Python (it is so much easier to develop and debug in Python)
and then in C/C++. Moreover, you need to add the stuff to convert
forward/backward from/to Python/C. 

> I think the question actually is more or less: would you be contented
> with a Python which produces compiled code which in turn executes 10
> times slower than an equivalent C code? Normally, Python executes code

No, why should the code be 10 times slower? Low-level objects
(numbers, arrays) can be manipulated exactly the same way in both
Python and C, so you should get the same speed. 

> And the next question: It is feasible to improve Python to that level?

Yes. If you add voluntary static typing, then in the section where the
compiler knows the type of every object, it can emit exactly the same
code as a C/C++ compiler would. In other section, we just go on
interpreting the bytecode.

> What about your experience with Scilab? Or even due to INRIA: OCaml?

I do not know SciLab. I am considering OCaml, I do not like the syntax too
much, and it seems there are no true optimizing compilers.

Jan

-- 
-------------------------------------------------------------------------
Jan Kybic <kybic at ieee.org>      Robotvis, INRIA, Sophia-Antipolis, France
       or <Jan.Kybic at sophia.inria.fr>,tel. work +33 492 38 7589, fax 7845
                    http://www-sop.inria.fr/robotvis/personnel/Jan.Kybic/