Paul Rubin, 04.08.2012 22:43: > Stefan Behnel writes: >>> Calling CPython hardly counts as compiling Python into C. >> CPython is written in C, though. So anything that CPython does can be >> done in C. It's not like the CPython project used a completely unusual >> way of writing C code. > > CPython is a relatively simple interpreter, and executing code > by invoking such an interpreter IMHO doesn't count as "compiling" it in > any meaningful way.
Oh, CPython is substantially more than an interpreter. The eval loop is only *one* way to use the runtime environment. Remember that it has many builtin types and functions as well as a huge standard library. Much of the runtime environment is already written in C or can be compiled down to C. If you compile Python code into C code that avoids the eval loop and only uses the CPython runtime environment (which is what Cython does), I think that qualifies as compiling Python code to C. It's definitely the most practical and user friendly way to do it. >> You will always need some kind of runtime infrastructure when you >> "compile Python into C", so you can just as well use CPython for that >> instead of reimplementing it completely from scratch. > > Maybe there's parts of Cpython you can re-use, but having the CPython > interpreter be the execution engine for "compiled" Python generators > again fails the seriousness test of what it means to compile code. If > you mean something other than that, you might explain more clearly. See above. >> Both Cython and Nuitka do exactly that, > > I didn't know about Nuitka; it looks interesting but (at least after a > few minutes looking) I don't have much sense of how it works. It's mostly like Cython but without the type system, i.e. without all the stuff that makes it useful in real life. Just a bare Python-to-C++-in-CPython compiler, without much of a way to make it do what you want. >> Last I heard, PyPy had a couple of GCs to choose from, > > PyPy doesn't compile to C RPython (usually) does, though, and my guess is that the memory management part of the runtime is written in RPython. > but I guess compiling to C doesn't preclude > precise GC, as long as the generated C code carefully tracks what C > objects can contain GC-able pointers, and follows some constraints about > when the GC can run. Some other compilers do this so it's not as big a > deal as it sounded like at first. OK. Yep, C really becomes a lot nicer when you generate it. >> Huh? LuaJIT is a reimplementation of Lua that uses an optimising JIT >> compiler specifically for Lua code. How is that similar to the Jython >> runtime that runs *on top of* the JVM with its generic byte code based >> JIT compiler? > > I thought LuaJIT compiles the existing Lua VM code, but I haven't > looked at it closely or used it. Ok. It obviously reuses code, but the VM part of it is really different from standard Lua. Stefan -- http://mail.python.org/mailman/listinfo/python-list
