Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nuitka Progress in 2015 – Python Compiler

nuitka.net

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Nuitka Progress in 2015 – Python Compiler

#41

Post by sametmax »

ChrisArgyle wrote: post #28
objectified wrote: post #10

Earlier quoted context omitted.

Being able to ship a self contained binary of your application is a very powerful concept, on which many seem to agree. 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…

> 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. Please excuse my newbness but doesn't python wheel do most of this (besides compiling to a single package)?

Not under linux, but it's coming. Alhough they have no way to include big dependancies like QT and the like.

Re: Nuitka Progress in 2015 – Python Compiler

#42

Post by sametmax »

wibr wrote: post #19

This looks very similar to Cython, which can also compile .py files without modification and is more mature at the moment. It seems that Nuitka wants to do a few things differently, though. The biggest difference is probably that Nuitka wants to use type inference + hints instead of explicit declarations, which make Cython code incompatible with CPython but give you more control and C interoperability. Edit: Thanks,…

No. Actually nuikta can take your core "as-is". It doesn't need any work of your part at all. And it embeds dependancies as well, without any change needed for them either. That's the game changer : take your Python program, call nuikta, get a standalone exe.

Re: Nuitka Progress in 2015 – Python Compiler

#43

Post by Lofkin »

falcolas wrote: post #26
scarygliders wrote: post #24

Earlier quoted context omitted.

cx_Freeze is still very effective for distribution - I use it all the time to produce a standalone version of my software and then I use Inno Setup to create an installer package for my customers. 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 inclu…

> The result should be that the same Python code should run much faster in the form created by Nuitka 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 c…

Nuitka is already faster than Cpython and it seems a majority of the speed work has yet to be done.

Re: Nuitka Progress in 2015 – Python Compiler

#44

Post by IshKebab »

_yy wrote: post #12
objectified wrote: post #10

Earlier quoted context omitted.

Being able to ship a self contained binary of your application is a very powerful concept, on which many seem to agree. 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…

Remember that critical Go security update? Usual procedure - update the shared library, restart affected services. Go - recompile everything.

Yeah that's the usual refrain, but the only situation where you have shared libraries is on Linux with a package manager. In that case it is trivial to recompile all packages that depend on the insecure library anyway.

On Windows you have to package most shared libraries with your app anyway so you have to get a new version of it anyway.

Re: Nuitka Progress in 2015 – Python Compiler

#45

Post by telotortium »

Pharaoh2 wrote: post #13
mtrn wrote: post #11

Earlier quoted context omitted.

Why is Go packaging terrible? Because we are going back to static binaries? 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 ver…

It great when you hold all the go code and can deploy fixed version anytime. It sucks ass when there is a critical vulnerability in libc and all your go based binaries was compiled against it and you are waiting for the vendors to issue patches instead of just being able to upgrade libc.so.

The default Go compiler, gc, doesn't link to libc at all on Linux, but directly uses system calls, whose interface is stable. It does link (dynamically, I think) against libc on OS X and Windows, since the system call interface is not stable there.

Re: Nuitka Progress in 2015 – Python Compiler

#47

Post by jvoorhis »

falcolas wrote: post #30
_yy wrote: post #27

Earlier quoted context omitted.

That's why Debian Stable and RHEL exist. Security patches don't break the API.

> Security patches don't break the API. 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.

And heaven help you if RedHat decides not to backport a critical bugfix. OpenSSL on CentOS 6 has 99 patch files, a script named "hobble-openssl" and non-trivial changes to the build system that affect linkage, making DIY backports less than trivial.

Re: Nuitka Progress in 2015 – Python Compiler

#48

Post by jerf »

_yy wrote: post #12
objectified wrote: post #10

Earlier quoted context omitted.

Being able to ship a self contained binary of your application is a very powerful concept, on which many seem to agree. 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…

Remember that critical Go security update? Usual procedure - update the shared library, restart affected services. Go - recompile everything.

Yeah, but... that's not really the "usual procedure" though. Nobody who knows what they are doing literally downloads openssl manually, compiles the new shared library, manually installs it, and manually restarts the affected services, on the grounds that if you do that you have just proved you don't know what you are doing. (Most charitably, you're doing a "Linux From Scratch" for educational purposes, but that's just about the only valid reason.) Once you have introduced package management and/or system management tools, it doesn't seem like a significantly different problem anymore, and likely to be utterly swamped by the other bigger problems that appear at scale.

Re: Nuitka Progress in 2015 – Python Compiler

#49

Post by scarygliders »

falcolas wrote: post #26
scarygliders wrote: post #24

Earlier quoted context omitted.

cx_Freeze is still very effective for distribution - I use it all the time to produce a standalone version of my software and then I use Inno Setup to create an installer package for my customers. 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 inclu…

> The result should be that the same Python code should run much faster in the form created by Nuitka 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 c…

I think you misunderstand what Nuitka is doing...

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.

Post reply on HN