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! -- https://mail.python.org/mailman/listinfo/python-list
