Why it is
I love Python. I am way more productive with Python than I ever imagined, even though I was once proficient in Perl. I have done low level decoding tasks in Python, most flexible Meta Programming for Test Frameworks and Domain Specific Languages.
All the while I thought that Python needed not really be slower than C is. Over the years, I learned how to optimize for the standard Python implementation which is called CPython, and more and more I also learned how CPython works.
What it is
So I thought there ought be a possibility to use the Python language and have a compiler, a better compiler than what CPython already has with its bytecode. This is what Nuitka is supposed to achieve.
It is is my attempt to translate pure Python not into bytecode, but into machine code (via C++ compiler), while using libpython at run time. And then to do compile time and also run time analysis to speculatively execute things in a faster mode if certain expectations are met.
License
I am at this time exclusively licensing all core part of mine from of Nuitka under GPLv3 and no other license, which means that for the parts of Nuitka copied to the generated code, you won’t have a license to distribute the source or binaries unless your project is compatible with that.
It’s my work, it’s my choice. At a later time, a new release of Nuitka shall be made available under “Apache License 2.0″, which allows to use Nuitka for every project, including Closed Source. Therefore I am asking you to put all changes you send to me or others you received Nuikta from, under this license as well already.
The re-license is expected to occur at Nuitka 1.0, when I consider it is “usable”. I am also going to make an announcement at PyCON EU about a time limit, should I go there this year.
Installation
You may also install packages for Debian, Arch, and Windows. To install from source, just extract the source tarball and execute “python setup.py install”.
For development inside the source code, use “eval `misc/create-environment.sh`” which will to setup the “PATH” variable, so that “nuitka” and “nuitka-python” are included. No heavy stuff, plus you may also also execute them directly from “bin” directory. On Windows there will be corresponding batch files in the “Scripts” directory of your installation.
Usage
Correctly installed, under Linux you can execute a program as simple as “nuitka-python bla.py” (Linux) or “nuitka –exe –execute bla.py” which will take longer to start than “python bla.py” does, but otherwise it will behave very similar.
It will leave a “bla.build” directory and a “bla.exe” file behind. By default they end up near the “bla.py” file specified, but there is a command line argument to control that.
If you compile an executable, it will attempt recurse into the imported modules (and give warnings if it wasn’t asked to do it, or can’t find it) and if it finds their Python source code (won’t work with “.so/.pyd” modules obviously), compile them all of them into one executable, which can take some time if it’s a big program.
What it gives
It is faster? Not really. Compiling takes a lot time, although it may be a one time action. At run time, performance comparisons with CPython show how well optimized CPython bytecode is interpreted. The compiled program is somewhat faster, currently pystone runs at 258% speed. But most often you will not yet notice any significant difference.
Status or Why again?
Well, this is clearly not the end of the line. The compiler does not do any important optimizations yet, mostly because this is only the priority as of recently and at the start, only the basics are being optimized. The code generation shall first be complete and correct, and now that it, basic operations are improved and cleaned up, so that the fallback to Python VM will be as fast as possible.
The differences to CPython are practically non-existent, and when discovered, they are quickly corrected. With each release it has become better and slowly reaches the point, where they cannot be reduced any further. This point has been reached, and I am willing to declare feature parity with CPython 2.6 and 2.7, which is a huge success.
Only once generated code is fully correct and the basics are in place, I will want to actually think about how to optimize it and see how to benefit from being a compiler in the first place. First steps of these are ongoing in a feature branch, but nothing usable is yet available.
Right, stable Nuitka is little more an emulation of the CPython bytecode compiler/runtime via C++ compiler/runtime, not much more.
Currently Nuitka passes everything of the CPython test suite that I find required. Although clearly much more than I ever though possible, e.g. builtins like “exec”, “eval”, “locals” or “dir” seemed to be more challenging, but are considered solved now. And effort to reduce the required differences even further is on the way too.
There were a lot of things that I never thought could exist, e.g. “func_code” attributes of function objects didn’t exist until 0.3.13, and I had previously thought the same of the function dictionary or weak references at the beginning of the project, and now all of these exist.
Trying to be compatible is an overarching goal of Nuitka and it is basically there now.
Download
Get the latest release from this page.
Final Words
Enjoy at your risk. While a lot of code runs in the same way, potentially not all of it may do that yet. At this stage I consider this release an “beta” release.