> SSA (Single State Assignment Form) Is this something different from static single assignment? I'm assuming not, but I've never heard SSA expanded in this form.
You are right, this should be static single assignment.
Nuitka Progress in 2015 – Python Compiler
31–40 of 55 posts
Re: Nuitka Progress in 2015 – Python Compiler
#32Does anyone know if this works with numpy?
It works with numpy. (I tried it and it seems to be 100% compatible, I haven't noticed any differences)
Re: Nuitka Progress in 2015 – Python Compiler
#33This 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
I imagine that type interference might be what an advocate of dynamically typed languages sees in statically typed languages.
Re: Nuitka Progress in 2015 – Python Compiler
#34This 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,…
Cython supports type inference, in the form of `infer_types` which can be used either as a compiler directive or a decorator (which means you can pick and choose, and control, when and where type inference is allowed to occur).
Re: Nuitka Progress in 2015 – Python Compiler
#35Earlier quoted context omitted.
Remember that critical Go security update? Usual procedure - update the shared library, restart affected services. Go - recompile everything.
Which only needs to happen once.
Yes but still. If you have a procedure in place to recompile and redeploy everything, you could just deploy the libraries as well.
Re: Nuitka Progress in 2015 – Python Compiler
#36Earlier quoted context omitted.
Which only needs to happen once.
Yes but still. If you have a procedure in place to recompile and redeploy everything, you could just deploy the libraries as well.
Plus, the system admin doesn't just have to wait on the new security-patched library to be ready, they have to wait for everyone who used Go to recompile and distribute their programs.
Re: Nuitka Progress in 2015 – Python Compiler
#37Re: Nuitka Progress in 2015 – Python Compiler
#38Earlier quoted context omitted.
Which only needs to happen once.
Yes but still. If you have a procedure in place to recompile and redeploy everything, you could just deploy the libraries as well.
So you're redeploying one binary instead of another binary. You still need to deploy something.
In fact, what about just switching connections to freshly launched VMs?
Re: Nuitka Progress in 2015 – Python Compiler
#39It's fantastic to see someone taking on the hard problems, things that take years to solve, especially if you're on your own. This is the essence of Open Source - take your time to do something right. Great stuff, good luck with it, we need more grand undertakings like this!
(This comment is mainly based on this talk: https://www.youtube.com/watch?v=a8RRbT4BTEw)
Re: Nuitka Progress in 2015 – Python Compiler
#40IMHO, 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.
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.
Pip and virtualenv solve the problem of creating and populating isolated runtimes for things you control. They don't really address distribution to end users, i.e., those who use OS packaging or app stores.
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.