On Wed, 2 Sep 2015 02:20 am, Marko Rauhamaa wrote: > Steven D'Aprano <st...@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 -- https://mail.python.org/mailman/listinfo/python-list
