Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Stefan Behnel <stefan_ml@behnel.de>
Subject: Re: On-topic: alternate Python implementations
Date: Sat, 04 Aug 2012 23:24:08 +0200
References: <501cbdf8$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.2924.1344062061.4697.python-list@python.org> <501cff63$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.2930.1344079082.4697.python-list@python.org> <7x1ujmabs9.fsf@ruckus.brouhaha.com> <mailman.2940.1344099318.4697.python-list@python.org> <7x1ujm1pwu.fsf@ruckus.brouhaha.com> <mailman.2945.1344107179.4697.python-list@python.org> <7xsjc2l766.fsf@ruckus.brouhaha.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
In-Reply-To: <7xsjc2l766.fsf@ruckus.brouhaha.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2951.1344115460.4697.python-list@python.org>
Lines: 75
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:26510

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