Nuitka Progress in 2015 – Python Compiler(nuitka.net) |
Nuitka Progress in 2015 – Python Compiler(nuitka.net) |
Edit: I see from your reply that we're talking at cross purposes. I thought you meant source distribution, but you mean binary distribution to end users or deployment to production systems, and in that case I agree with you.
The way I see it, pip and virtualenv are not practical for deployment or distribution. You shouldn't have to download and install things during a production deployment. I even created a tool (https://github.com/objectified/vdist) to mitigate this problem, but it will always be a hack when doing it this way.
Distribution of python "binaries" is a real pain though. Twitter's PEX (https://engineering.twitter.com/university/videos/wtf-is-pex) is the best, in my opinion. (It's basically a packaged venv, so in that regard, I guess I agree.) It's still problematic and requires a writable filesystem just to run.
I build OS packages for python programs using PEX, and it's okay, but it's probably my least favorite distribution mechanism.
I write and ship Go and Python code every day and I found that distribution is a great overall benefit - one, that some developers for some reason seem to ignore.
It's not just convenient for me, but for various other parts of a project as well: less moving parts is welcomed by ops, fast iterations help to meet the requirements. Overall a very positive impact for a reasonable price tag: larger binaries and recompilation overhead, when a critical library that is used needs a fix.
The only drawback is that you have the decompression time when starting the software, but in my case, the customers have not noticed it yet.
Edit: The advantages of Nuitka are that as you compile your code to C++, you make it faster and also protect it against easy reverse engineering. This could be interesting to compile the critical parts of your application with Nuitka and pack the rest with PyInstaller.
As Loic states, Nuitka works differently from cx_Freeze in that Nuitka takes your Python source, compiles that to C++, then compiles the C++, whereas cx_Freeeze creates Python bytecode which is subsequently run by the included Python interpreter.
The result should be that the same Python code should run much faster in the form created by Nuitka, than the result created by cx_Freeze.
By those that never used an AOT compiler to native code.
Other than that, Given that Lisp, Dylan always had AOT compilers, it would be nice if Python eventually had something similar.
Wow. That is amazing! Pyston only supports Python 2 and PyPy is working on it.
Nuitka looks very promising.
Edit: Thanks, no more interference!
interference - obstruction, collision
inference - deduction, derivation
I suggested the tl;dr section to Kay in the Overview ;)
I've also donated to the guy. I'd help out in the development, but to be honest a lot of what he's doing goes way over my head and I don't have the time to sit down and try to understand it all.
I encourage others better than me to help in Nuitka's development :)
Is this something different from static single assignment? I'm assuming not, but I've never heard SSA expanded in this form.
(This comment is mainly based on this talk: https://www.youtube.com/watch?v=a8RRbT4BTEw)
Edit: Ok, now I see that the "Overview" button is hidden on mobile.
How do you figure? Python's slowness is not due to it's lack of compilation, it's due to its dynamic nature and all of the runtime lookups.
Past efforts to compile python down to bytecode have not resulted in speedups. Unladen Swallow is one such failed example. PyPy gets around this by analyzing the actual running code and is only able to speed up a subset of all of Python.
It is not compiling down to Python bytecode.
It is compiling to an operational-equivalent C++ source code.
Then it is compiling that C++ code to executable object code.
Usual procedure - update the shared library, restart affected services. Go - recompile everything.
What's the issue with that?
On Windows you have to package most shared libraries with your app anyway so you have to get a new version of it anyway.
... look for programs to break at runtime because of some unrelated API change in the shared library.
Please excuse my newbness but doesn't python wheel do most of this (besides compiling to a single package)?
In fact, what about just switching connections to freshly launched VMs?
shouldn't
When the patched library is not part of Debian Stable or RHEL's repositories (for example, if you require features from a release less than a year old) all bets of API stability are off.
OpenSSL and libc are not the only libraries which are patched for security that people use.