Compiling

[Paul Boddie]

Simon Faulkner wrote:
>
> I love Python for it's ease and speed of development especially for the
> "Programming Challenged" like me but why hasn't someone written a
> compiler for Python?

There are various compilers for Python, but they vary in terms of
capabilities, language support and method of operation. Disregarding
Jython and the jythonc tool, which I believe is somewhat inspired by
earlier tools for CPython, there has been a fair amount of activity and
a number of works and/or papers on the topic.

First of all, there have been conventional compilers such as "Python to
C" [1] and other early attempts to do similar things [2, 3, 4]; such
work possibly informed the construction of some of the
bundler/installer tools [5]. Then, there were later attempts such as
Starkiller [6] to produce low-level language code, and also compilers
which produce other high-level languages [7, 8]. Most of the
aforementioned projects have attempted to deal with "normal" Python,
possibly with the exception of Starkiller. Subsequent works which deal
with more restricted dialects of Python include ShedSkin [9].

Then, there are hybrid language compilers such as Pyrex [10] which
avoid the issues of turning highly dynamic Python code into some
low-level representation by allowing programmers to write
speed-critical sections in a special Python dialect which translates
better into C/C++. Finally, there are just-in-time compilers such as
Psyco [11] which make use of run-time information to generate machine
code specialised for the operations being performed; the PyPy project
[12] appears to have such concerns in mind in the design of possible
replacement virtual machines for Python.

> I guess it's not that simple eh?

Well, there have been other projects, too. Once upon a time there was a
promising alternative implementation of Python called Vyper [13, 14]
but work on that was discontinued. One prematurely-hyped work, pycore
[15], involved translating Python to Smalltalk but disappeared almost
instantly.

I believe that many Python programmers who are vocal on such topics
don't want to surrender any of the functionality that they've become
accustomed to, and with additional functionality arriving all the time
in CPython, it's arguably difficult to reconcile such functionality
with performant low-level code generation (at least in advance of
run-time). That said, there has been a movement to introduce static
typing, ostensibly for reliability purposes, but such justifications
have arguably arisen because claims about the various proposed typing
models and performance have largely gone unproven.

Paul

[1] http://sourceforge.net/projects/p2c/
[2] http://www.python.org/workshops/1996-06/papers/hugunin.IPCIV.html
[3]
http://www.foretec.com/python/workshops/1998-11/proceedings/papers/riehl/riehl.html
[4]
http://www.foretec.com/python/workshops/1998-11/proceedings/papers/aycock-211/aycock211.html
[5] http://davidf.sjsoft.com/mirrors/mcmillan-inc/install1.html
[6] http://www.python.org/pycon/dc2004/papers/1/
[7] http://perthon.sourceforge.net/
[8]
http://www.python.org/workshops/2000-01/proceedings/papers/aycock/aycock.html
[9] http://sourceforge.net/projects/shedskin/
[10] http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
[11] http://psyco.sourceforge.net/
[12] http://codespeak.net/pypy/dist/pypy/doc/news.html
[13] http://monkeyfist.com/articles/266
[14] http://gnosis.cx/publish/programming/charming_python_8.html
[15]
http://webpages.charter.net/allanms/2004/08/you-dont-tug-on-supermans-cape.html