Why Python is not both an interpreter and a compiler?

[Marko Rauhamaa]

Steven D'Aprano <steve at pearwood.info>:

> On Wed, 2 Sep 2015 02:20 am, Marko Rauhamaa wrote:
>> 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.

Yes, virtually all Linux software builds upon dynamic libraries that
have been introduced to the linker via ldconfig.

> 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.

I wasn't trying to solve that particular problem. I was simply stating
you could compile (translate, turn) a Python program into a single,
executable file.

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

If your application consists of a single .py file, why not?

>> 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.

Again, having a Python interpreter around is not the issue I'm talking
about. I'm talking about the possibility to compile (translate, turn) a
Python program into a single, executable file.

Now, even C programs can suffer from the module problem: you sometimes
need to ship extra dynamic libraries ("modules") with your binary.


Marko