Why Python is not both an interpreter and a compiler?

[Michael Torrie]

On 08/31/2015 02:35 AM, Mahan Marwat wrote:
> What I know about an interpreter and a compiler is: they both convert
> source code to machine code and the only difference is, an
> interpreter convert it, line by line while compiler convert the whole
> source file. Now if we compile a C source file on C compiler, it will
> produce a small executable file. But if we compile (freeze) a Python
> source file on Python interpreter (using cx_freeze), it will produce
> a big executable file. Now the thing is C compiler does not embed a C
> compiler inside our program, while the Python interpreter (cx_freeze,
> pytoexe) embed Python interpreter inside our program, what is the
> reason? The question is, why cx_freeze etc... embed Python
> interpreter inside our programs, they are unable to produce machine
> code like C compiler do? Cant we program a language, which is both
> interpreted and compiled? The core developer cant add the compiling
> functionality to Python?

It think your questions have been well answered by others.  But there
are several attempts at making an actual python compiler.  Often this
involve less-dynamic subset of Python.  For example, pypy has a dialect
called rpython which compiles straight to C++ code, and then to machine
code.

Another subset compiler is cython, which is somewhat of a specialized
compiler. It compiles a subset of Python to a binary shared library that
can be imported into a Python program running in the normal interpreter.

The dynamic nature of Python means that probably your best route to
speed is going to be through just-in-time compilation. The pypy project
is an attempt to do JIT with Python. So far the results are very
promising.  Pretty cool since pypy is written in Python and bootstraps
from the standard python interpreter.

Lastly, one attempt at a compiler is nuitka (google it).  It produces
self-contained executables.  Nuitka compiles what it can, and interprets
the rest (if I understand it correctly) by embedding libpython itself in
the executable.  At this time, nuitka isn't focusing on performance,
more correctness.  GvR doesn't really think much of nuitka, but I think
it's a cool project and the developer is a nice guy.  Maybe have its uses.

So far I haven't had a use for nuikta; cPython is enough for me, with
cython for compiling functions that need some more raw speed.  I tend to
use more conventional optimization techniques that work just fine with
the interpreter.  And often the results are fast enough.  For example I
implemented a simple memoization wrapper for a particularly expensive
function that was called a lot, often over the same inputs several
times.  Runtime went from 10 seconds to less than 1.  Enough for me!