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

21–30 of 55 posts

Re: Nuitka Progress in 2015 – Python Compiler

#21

Post by qb45 »

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,…

I've never heard about type inTERference, but I'm sure that if something like that existed, it would have little to do with type inference which you probably meant :)

interference - obstruction, collision

inference - deduction, derivation

Re: Nuitka Progress in 2015 – Python Compiler

#23

Post by scarygliders »

It's been great watching Nuitka progress over the past couple of years.

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 :)

Re: Nuitka Progress in 2015 – Python Compiler

#24

Post by scarygliders »

fulafel wrote: post #17
objectified wrote: post #7

IMHO, this is a very important project as it makes up for one of the biggest shortcomings in the Python ecosystem - distribution of software. Distribution is clearly one of the reasons that Go is so popular. It would be great if we could take advantage of Python as a language and Python as an ecosystem while still being able to deploy as if it was a walk in the park.

Last time I needed single-executable distribution with Python (admittedly a while ago), there were easy to use "freeze" tools for this that worked really well. A cursory web search suggests that cx_Freeze is the current popular tool for it. Has the situation tehnically deteriorated or are people unaware of these Python tools now?

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 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.

Re: Nuitka Progress in 2015 – Python Compiler

#25

Post by falcolas »

_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.

> update the shared library, restart affected services

... look for programs to break at runtime because of some unrelated API change in the shared library.

Re: Nuitka Progress in 2015 – Python Compiler

#26

Post by falcolas »

scarygliders wrote: post #24
fulafel wrote: post #17

Earlier quoted context omitted.

Last time I needed single-executable distribution with Python (admittedly a while ago), there were easy to use "freeze" tools for this that worked really well. A cursory web search suggests that cx_Freeze is the current popular tool for it. Has the situation tehnically deteriorated or are people unaware of these Python tools now?

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 code and is only able to speed up a subset of all of Python.

Re: Nuitka Progress in 2015 – Python Compiler

#27

Post by _yy »

falcolas wrote: post #25
_yy wrote: post #12

Earlier quoted context omitted.

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

> update the shared library, restart affected services ... look for programs to break at runtime because of some unrelated API change in the shared library.

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

Re: Nuitka Progress in 2015 – Python Compiler

#28

Post by ChrisArgyle »

objectified wrote: post #10
rwmj wrote: post #8

Earlier quoted context omitted.

I find the way software is packaged in Go to be a terrible regression, but I'm more interested in why you think pip and venv's don't solve the problem for Python already? 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.

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)?

Re: Nuitka Progress in 2015 – Python Compiler

#29

Post by zwischenzug »

_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.

Which only needs to happen once.

Re: Nuitka Progress in 2015 – Python Compiler

#30

Post by falcolas »

_yy wrote: post #27
falcolas wrote: post #25

Earlier quoted context omitted.

> update the shared library, restart affected services ... look for programs to break at runtime because of some unrelated API change in the shared library.

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.

Post reply on HN