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 -- http://mail.python.org/mailman/listinfo/python-list
