Why Python is not both an interpreter and a compiler?

[Steven D'Aprano]

On Wed, 2 Sep 2015 02:20 am, Marko Rauhamaa wrote:

> Steven D'Aprano <steve at pearwood.info>:
> 
>> I believe that Marko is wrong. It is not so easy to compile Python to
>> machine language for real machines. That's why the compiler targets a
>> virtual machine instead.
> 
> Somehow Guile manages it even though Scheme is at least as dynamic a
> language as Python.

It's not about the dynamicism precisely, it's about what counts as primitive
data types and operations.

What are the primitives in Scheme? In Python, the primitives are pretty
complex. I don't know how accurate this page is:

https://en.wikibooks.org/wiki/Scheme_Programming/Scheme_Datatypes

but it suggests that Scheme primitives are quite close to the machine. That
may keep the runtime small.


> I never said a compiler would translate Python to (analogous) machine
> language. I said you could easily turn CPython into a dynamic library
> (run-time environment) and write a small bootstrapper that you package
> into an executable archive with the Python code (whether .py or .pyc).
> What results is a single executable that you can run analogously to any
> other command.

Provided you have the correct version of the dynamic library installed in
the correct place. 

But this doesn't solve the problem of being able to distribute a single
executable file that requires no pre-installed libraries, which is the
problem cx_freeze and pytoexe are made to solve. They solve the case when
you can't assume that there is a Python run-time environment available.

If you are going to require a Python run-time environment, let's call
it "pylib", then you might as well require the python compiler and standard
library be installed. (In the case of C, that's not the case, a distinct
run-time environment makes sense, as the compile-time and run-time
environments are sharply delineated in C. One certainly wouldn't want to
have to re-compile the average C application each and every time you run
it.)

Maybe you could separate the REPL and remove it from pylib, but that's
probably quite small, it might not make that much of a difference to the
total size.

Maybe you could build a pylib that was significantly smaller than the Python
interpreter plus stdlib. That's fine, I'm not arguing it can't be done. I'm
arguing that it's not *easy*, if it were easy somebody likely would have
done it by now.

I don't know the state of the art here. Does Cython work in this space? How
about Nuitka?


> In fact, the shebang notation turns any single .py file into such an
> executable.

I trust that you're not actually arguing that distributing .py files meets
the requirement for a standalone application.


> The problem is if you break your program into modules. Java, 
> of course, solved a similar problem with .jar files (but still wouldn't
> jump over the final hurdle of making the .jar files executable).

You can distribute your Python app as a zip file, except of course you still
need the Python interpreter to be installed.



-- 
Steven