

Python Frontend for GCC - srean
http://gcc.gnu.org/wiki/PythonFrontEnd

======
srean
This started of as a Google Summer of code project last year but is very
active [http://code.redbrain.co.uk/cgit.cgi/gcc-dev/log/?h=python-
de...](http://code.redbrain.co.uk/cgit.cgi/gcc-dev/log/?h=python-dev)

What I find quite interesting is that they are going for full compatibility
with Python and not some Pythonic language of somewhat restricted dynamism
like rpython, shed-skin, unpython or wirbel, well to an extent cython too. So
they will require quite an elaborate runtime library. It will be good if they
support optional type annotations like unpython, in the interest of runtime
efficiency. The good thing is that unpython programs continue to be valid
python code even with those annotations. And if they bake in true tail
recursion that would be awesome, not very unrealistic, given that gcc supports
tail call optimization for a number of scenarios.

~~~
TillE
> So they will require quite an elaborate runtime library.

No kidding. The most realistic methods for compiling Python are probably
something like Nuitka, which basically turns Python code into CPython API
calls, bypassing the step of parsing bytecode at runtime. So it started out
100% compatible with CPython but only marginally faster, and then they started
adding some optimizations.

[http://kayhayen24x7.homelinux.org/blog/nuitka-a-python-
compi...](http://kayhayen24x7.homelinux.org/blog/nuitka-a-python-compiler/)

------
sambeau
Ian Lance Taylor is the creator and maintainer of gccgo the Go front-end for
gcc.

<http://golang.org/doc/gccgo_install.html>

He also has an interesting blog:

<http://www.airs.com/blog/>

~~~
danieldk
Not only that, he is also the developer of the gold linker (and binutils
maintainer from 1996 to 1999): <https://lwn.net/Articles/274859/>

------
rbanffy
I wish Philip and Lance the best of luck. Making this work is a very ambitious
goal and we'll all learn a lot from it. And hopefully, get a bunch of new and
shiny toys.

------
IgorPartola
Does anyone have an idea of how difficult this will be? Is this going to be
another Unladen Swallow project, where the research is really cool, but it
never can get to be production ready, or should I be getting excited for being
able to write production code against this toolchain in a few years?

~~~
kingkilr
a) Unladen Swallow wasn't research, in fact it was explicitly "just
engineering".

b) I _seriously_ doubt this goes anywhere, Python is simply not amenable to
productive static analysis.

~~~
rayiner
Static whole program type analysis is pretty much a lost cause for any
production compiler.

------
bcl
Interesting project, and I wish them luck. But Python is really not suitable
as a compiled language. Its ability to change what any object is, on the fly,
really throws a wrench into things. I think efforts like PyPy are much more
likely to produce improvements in execution speed.

~~~
rayiner
Common Lisp supports that --- it doesn't really much with compilation too
much.

~~~
sedachv
Not only that, there is already a Python implementation that compiles to
Common Lisp (<http://common-lisp.net/project/clpython/>), so you can get
native code compilation for Python by running CLPython on any of the Common
Lisp compilers that produce native code.

IMO, I don't see the point of working on static compilers for languages with
simple meta-circular semantics at this point in time. LuaJIT has proven beyond
doubt that tracing JIT compilation is the way to go.

------
fleitz
Is there another group doing this with LLVM?

~~~
maximilianburke
There was the Unladen Swallow project but it was different in a few areas. The
Python front end seeks to create an ahead of time compiler for GCC, whereas
Unladen Swallow used LLVM's just-in-time compilation framework. Ahead of time
compilation could be quite beneficial to applications like smartphones or
video games that could benefit from a faster Python environment but don't
allow JITs like PyPy or Unladen Swallow. (License permitting.) The Python
front end is also being actively developed right now whereas US seems to have
petered out.

