Nuitka Release 0.5.4    Posted:


This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler. Please see the page "What is Nuitka?" for an overview.

This release is aiming at preparatory changes to enable optimization based on SSA analysis, introducing a variable registry, so that variables no longer trace their references to themselves.

Otherwise, MinGW64 support has been added, and lots of bug fixes were made to improve the compatibility.

New Optimization

  • Using new variable registry, now properly detecting actual need for sharing variables. Optimization may discover that it is unnecessary to share a variable, and then it no longer is. This also allows --debug without it reporting unused variable warnings on Python3.
  • Scons startup has been accelerated, removing scans for unused tools, and avoiding making more than one gcc version check.

Bug Fixes

  • Compatibility: In case of unknown encodings, Nuitka was not giving the name of the problematic encoding in the error message. Fixed in 0.5.3.3 already.
  • Submodules with the same name as built-in modules were wrongly shadowed. Fixed in 0.5.3.2 already.
  • Python3: Added implementations of is_package to the meta path based loader.
  • Python3.4: Added find_spec implementation to the meta path based loader for increased compatiblity.
  • Python3: Corrections for --debug to work with Python3 and MSVC compiler more often.
  • Fixed crash with --show-scons when no compiler was found. Fixed in 0.5.3.5 already.
  • Standalone: Need to blacklist lib2to3 from standard libary as well. Fixed in 0.5.3.4 already.
  • Python3: Adapted to changes in SyntaxError on newer Python releases, there is now a msg that can override reason.
  • Standalone Windows: Preserve sys.executable as it might be used to fork binaries.
  • Windows: The caching of Scons was not arch specific, and files could be used again, even if changing the arch from `x86 to x86_64 or back.
  • Windows: On 32 bit Python it can happen that with large number of generators running concurrently (>1500), one cannot be started anymore. Raising an MemoryError now.

Organizational

  • Added support for MinGW64. Currently needs to be run with PATH environment properly set up.
  • Updated internal version of Scons to 2.3.2, which breaks support for VS 2008, but adds support for VS 2013 and VS 2012. The VS 2013 is now the recommended compiler.
  • Added RPM package and repository for RHEL 7.
  • The output of --show-scons now includes the used compiler, including the MSVC version.
  • Added option --msvc to select the MSVC compiler version to use, which overrides automatic selection of the latest.
  • Added option -python-flag=no_warnings to disable user and deprecation warnings at run time.
  • Repository for Ubuntu Raring was removed, no more supported by Ubuntu.

Cleanups

  • Made technical and logical sharing decisions separate functions and implement them in a dedicated variable registry.
  • The Scons file has seen a major cleanup.

Summary

This release is mostly a maintenance release. The Scons integrations has been heavily visited, as has been Python3 and esp. Python3.4 compatibility, and results from the now possible debug test runs.

Standalone should be even more practical now, and MinGW64 is an option for those cases, where MSVC is too slow.

Comments

Nuitka Release 0.5.3    Posted:


This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler. Please see the page "What is Nuitka?" for an overview.

This release is mostly a follow up, resolving points that have become possible to resolve after completing the C-ish evolution of Nuitka. So this is more of a service release.

New Features

  • Improved mode --improved now sets error lines more properly than CPython does in many cases.
  • The -python-flag=-S mode now preserves PYTHONPATH and therefore became usable with virtualenv.

New Optimization

  • Line numbers of frames no longer get set unless an exception occurs, speeding up the normal path of execution.
  • For standalone mode, using --python-flag-S is now always possible and yields less module usage, resulting in smaller binaries and faster compilation.

Bug Fixes

  • Corrected an issue for frames being optimized away where in fact they are still necessary. Issue#140. Fixed in 0.5.2.1 already.
  • Fixed handling of exception tests as side effects. These could be remainders of optimization, but didn't have code generation. Fixed in 0.5.2.1 already.
  • Previously Nuitka only ever used the statement line as the line number for all the expression, even if it spawned multiple lines. Usually nothing important, and often even more correct, but sometimes not. Now the line number is most often the same as CPython in full compatibility mode, or better, see above. Issue#9.
  • Python3.4: Standalone mode for Windows is working now.
  • Standalone: Undo changes to PYTHONPATH or PYTHONHOME allowing potentially forked CPython programs to run properly.
  • Standalone: Fixed import error when using PyQt and Python3.

New Tests

  • For our testing approach, the improved line number handling means we can undo lots of changes that are no more necessary.
  • The compile library test has been extended to cover a third potential location where modules may live, covering the matplotlib module as a result.

Cleanups

  • In Python2, the list contractions used to be re-formulated to be function calls that have no frame stack entry of their own right. This required some special handling, in e.g. closure taking, and determining variable sharing across functions.

    This now got cleaned up to be properly in-lined in a try/finally expression.

  • The line number handling got simplified by pushing it into error exits only, removing the need to micro manage a line number stack which got removed.

  • Use intptr_t over unsigned long to store fiber code pointers, increasing portability.

Organizational

  • Providing own Debian/Ubuntu repositories for all relevant distributions.
  • Windows MSI files for Python 3.4 were added.
  • Hosting of the web site was moved to metal server with more RAM and performance.

Summary

This release brings about structural simplification that is both a followup to C-ish, as well as results from a failed attempt to remove static "variable references" and be fully SSA based. It incorporates changes aimed at making this next step in Nuitka evolution smaller.

Comments

Nuitka Release 0.5.2    Posted:


This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler. Please see the page "What is Nuitka?" for an overview.

This is a major release, with huge changes to code generation that improve performance in a significant way. It is a the result of a long development period, and therefore contains a huge jump ahead.

New Features

  • Added experimental support for Python 3.4, which is still work in progress.
  • Added support for virtualenv on MacOS.
  • Added support for virtualenv on Windows.
  • Added support for MacOS X standalone mode.
  • The code generation uses no header files anymore, therefore adding a module doesn't invalidate all compiled object files from caches anymore.
  • Constants code creation is now distributed, and constants referenced in a module are declared locally. This means that changing a module doesn't affect the validity of other modules object files from caches anymore.

New Optimization

  • C-ish code generation uses less C++ classes and generates more C-like code. Explicit temporary objects are now used for statement temporary variables.
  • The constants creation code is no more in a single file, but distributed across all modules, with only shared values created in a single file. This means improved scalability. There are remaining bad modules, but more often, standalone mode is now fast.
  • Exception handling no longer uses C++ exception, therefore has become much faster.
  • Loops that only break are eliminated.
  • Dead code after loops that do not break is now removed.
  • The try/finally and try/except constructs are now eliminated, where that is possible.
  • The try/finally part of the re-formulation for print statements is now only done when printing to a file, avoiding useless node tree bloat.
  • Tuples and lists are now generated with faster code.
  • Locals and global variables are now access with more direct code.
  • Added support for the anonymous code type built-in.
  • Added support for compile built-in.
  • Generators that statically return immediately, e.g. due to optimization results, are no longer using frame objects.
  • The complex call helpers use no pseudo frames anymore. Previous code generation required to have them, but with C-ish code generation that is no more necessary, speeding up those kind of calls.
  • Modules with only code that cannot raise, need not have a frame created for them. This avoids useless code size bloat because of them. Previously the frame stack entry was mandatory.

Bug Fixes

  • Windows: The resource files were cached by Scons and re-used, even if the input changed. The could lead to corrupted incremental builds. Issue#129. Fixed in 0.5.1.1 already.
  • Windows: For functions with too many local variables, the MSVC failed with an error "C1026: parser stack overflow, program too complex". The rewritten code generation doesn't burden the compiler as much. Issue#127.
  • Compatibility: The timing deletion of nested call arguments was different from C++. This shortcoming has been addressed in the rewritten code generation. Issue#62.
  • Compatibility: The __future__ flags and CO_FREECELL were not present in frame flags. These were then not always properly inherited to eval and exec in all cases.
  • Compatibility: Compiled frames for Python3 had f_restricted attribute, which is Python2 only. Removed it.
  • Compatibility: The SyntaxError of having a continue in a finally clause is now properly raised.
  • Python2: The exec statement with no locals argument provided, was preventing list contractions to take closure variables.
  • Python2: Having the ASCII encoding declared in a module wasn't working.
  • Standalone: Included the idna encoding as well. Issue#135.
  • Standalone: For virtualenv, the file orig-prefix.txt needs to be present, now it's copied into the "dist" directory as well. Issue#126. Fixed in 0.5.1.1 already.
  • Windows: Handle cases, where Python and user program are installed on different volumes.
  • Compatibility: Can now finally use execfile as an expression. Issue#5 is finally fixed after all this time thanks to C-ish code generation.
  • Compatibility: The order or call arguments deletion is now finally compatible. Issue#62 also is finally fixed. This too is thanks to C-ish code generation.
  • Compatibility: Code object flags are now more compatible for Python3.
  • Standalone: Removing "rpath" settings of shared libraries and extension modules included. This makes standalone binaries more robust on Fedora 20.
  • Python2: Wasn't falsely rejecting unicode strings as values for int and long variants with base argument provided.
  • Windows: For Python3.2 and 64 bits, global variable accesses could give false NameError exceptions. Fixed in 0.5.1.6 already.
  • Compatibility: Many exec and eval details have become more correctly, the argument handling is more compatible, and e.g. future flags are now passed along properly.
  • Compatibility: Using open with no arguments is now giving the same error.

Organizational

  • Replying to emails of the issue tracker works now.
  • Added option name alias --xml for --dump-xml.
  • Added option name alias --python-dbg for --python-debug, which actually might make it a bit more clear that it is about using the CPython debug run time.
  • Remove option --dump-tree, it had been broken for a long time and unused in favor of XML dumps.
  • New digital art folder with 3D version of Nuitka logo. Thanks to Juan Carlos for creating it.
  • Using "README.rst" instead of "README.txt" to make it look better on web pages.
  • More complete white-listing of missing imports in standard library. These should give no warnings anymore.
  • Updated the Nuitka GUI to the latest version, with enhanced features.
  • The builds of releases and update of the downloads page is now driven by Buildbot. Page will be automatically updated as updated binaries arrive.

Cleanups

  • Temp keeper variables and the nodes to handle them are now unified with normal temporary variables, greatly simplifying variable handling on that level.
  • Less code is coming from templates, more is actually derived from the node tree instead.
  • Releasing the references to temporary variables is now always explicit in the node tree.
  • The publishing and preservation of exceptions in frames was turned into explicit nodes.
  • Exception handling is now done with a single handle that checks with branches on the exception. This eliminates exception handler nodes.
  • The dir built-in with no arguments is now re-formulated to locals or globals with their .keys() attribute taken.
  • Dramatic amounts of cleanups to code generation specialties, that got done right for the new C-ish code generation.

New Tests

  • Warnings from MSVC are now error exits for --debug mode too, expanding the coverage of these tests.
  • The outputs with python-dbg can now also be compared, allowing to expand test coverage for reference counts.
  • Many of the basic tests are now executable with Python3 directly. This allows for easier debug.
  • The library compilation test is now also executed with Python3.

Summary

This release would deserve more than a minor number increase. The C-ish code generation, is a huge body of work. In many ways, it lays ground to taking benefit of SSA results, that previously would not have been possible. In other ways, it's incomplete in not yet taking full advantage yet.

The release contains so many improvements, that are not yet fully realized, but as a compiler, it also reflects a stable and improved state.

The important changes are about making SSA even more viable. Many of the problematic cases, e.g. exception handlers, have been stream lined. A whole class of variables, temporary keepers, has been eliminated. This is big news in this domain.

For the standalone users, there are lots of refinements. There is esp. a lot of work to create code that doesn't show scalability issues. While some remain, the most important problems have been dealt with. Others are still in the pipeline.

More work will be needed to take full advantage. This has been explained in a separate post in greater detail.

Comments

Yup, another Python Quiz    Posted:


Using the following source code as a test happily in my Python compiler Nuitka for some years now.

# Testing dict optimization with all constants for compatibility.
print(
    "Dictionary entirely from constant args", dict(
        q='Guido',
        w='van',
        e='Rossum',
        r='invented',
        t='Python',
        y=''
     )
)

Quiz Question

Lately, when adding Python 3.4 support, this and other code changed. So lets do this manually:

PYTHONHASHSEED=0 python3.3
Python 3.3.5 (default, Mar 22 2014, 13:24:53)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> dict(
...                q='Guido',
...                w='van',
...                e='Rossum',
...                r='invented',
...                t='Python',
...                y=''
...             )
{'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van', 'y': ''}
>>> {'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van', 'y': ''}
{'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van', 'y': ''}
>>> {'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van', 'y': ''}
{'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van', 'y': ''}
>>> {'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van', 'y': ''}
{'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van', 'y': ''}

See, the dictionary is stable, once it gets reordered, due to hash values, but then it stays fixed. Which is pretty OK, and using a fixed hash value, it's determinstic. Random hashing is not good for comparison testing, so I disable it for tests.

Now things get interesting, repeat with 3.4:

PYTHONHASHSEED=0 python3.4
Python 3.4.1rc1 (default, May  5 2014, 14:28:34)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> dict(
...                q='Guido',
...                w='van',
...                e='Rossum',
...                r='invented',
...                t='Python',
...                y=''
...             )
{'y': '', 'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van'}
>>> {'y': '', 'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van'}
{'r': 'invented', 'q': 'Guido', 'y': '', 'e': 'Rossum', 't': 'Python', 'w': 'van'}
>>> {'y': '', 'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van'}
{'r': 'invented', 'q': 'Guido', 'y': '', 'e': 'Rossum', 't': 'Python', 'w': 'van'}
>>> {'y': '', 'q': 'Guido', 'r': 'invented', 'e': 'Rossum', 't': 'Python', 'w': 'van'}
{'r': 'invented', 'q': 'Guido', 'y': '', 'e': 'Rossum', 't': 'Python', 'w': 'van'}

Nuitka builds this as the argument dictionary, before it is
passed to dict. Since it's all compile time constants, we can do that, right, and
we can use the result instead. So see this:

Look at how the result of "dict" is not reproducing itself, when used as a constant. I am only feeding the dict result to the interpreter, and it changes.

So the quizz this time is, why does this happen. What change in CPython3.4 makes this occur. Obviously it has to do with dictionary sizes.

Solution

I had a theory, but I couldn't confirm it looking at all of CPython sources "ceval.c" and "dictobject.c" differences between the two versions.

I am suspecting a difference between presized and non-presized dictionaries, or that change to dictionary grow. When dict is being called, the amount of keys is know though, as well as when building the constant. So this ought to not play any role.

Hm, actually. I don't know the solution yet. :-)

Comments

State of Nuitka    Posted:


For quite some time, publicly, very little has happend with my Python compiler Nuitka. But that doesn't mean, there hasn't been progress. In fact it is tremendous. I would like to have a post that kind of summarizes, what happened.

The last release, 0.5.1 was more of a maintainence release than making real changes. It turns out, that the bigger changes got delayed by a feature that I have described as "C-ish". Let me outline, what this means.

C-ish vs. C++-ish

When I started working on Nuitka, the big question was if it is possible to create a sufficiently compatible compiler. The use of C++11 then, together with some templates made it easy to cover a wide, wide part of the language, and to fully integrate with CPython for compatibility.

The main goal was to get it going to work correctly. As time went on, execution order demanded to do away with variadic templates, raw strings were not all that perfect at all, and so C++-03 was good enough at one point.

And then, as Nuitka became less and less template based, and shoving more things into the node tree, and re-formulations, making this where the knowledge resided. It became more and more obvious that C++ has two problems. One in the way I used it. One inherent in the language typical implementations:

  • C++ exceptions are god damn slow
  • Everything should be a in a single statement.

The later was my choice. Initially it made it easy to pass on references and put the releasing C++ class around every expression as necessary. Identifier classes were allowing for code generation to avoid taking references where necessary, and it was not all that bad. Yet limiting.

This led to a couple of issues.

  • The order of call arguments release for e.g. f(g(h())) was not completely compatible, with the way how CPython does it. C++ destructors for objects living in a single statement didn't give sufficient control, and make the order and timing of finalization not compatible.
  • The generated C++ code complexity became large. The compilation of the generated C++ in some cases was huge. To the point, that e.g. "code too complex" was giving by compilers like MSVC for some modules.
  • Cases of in-place assignments were discovered, where CPython outperforms Nuitka by a large margin. But these don't fit into that style of code generation.

So, at some point, the pain had built up. Code generation was already lighter than in the beginning. For example, initially with statements had dedicated code templates to them. This, and many other things, are long gone.

I took a deep dive, and rewrote the whole code generation, to be much more "C-ish" than "C++-ish". A huge undertaking that would take months.

  • Where previously, code didn't have to handle return error codes (a C++ exception was thrown), now everything needed a return value name, and error check.
  • Where classes were previously conviently made sure things happened at function or scope exit, manual handling needed to be added.
  • The handling of continue, break, and return was previously done with exceptions being thrown, if they were to pass a try/finally handler. Now these are done with stacks of exit handlers, where goto statements are used to produce the correct behaviour.

Rewriting Code Generation

Redoing code generation, over months, while ultimately, slowly, arriving at a point where Nuitka would be doing this, it already did before, was kind of frustrating.

Of course, the performance benefit would be there, but it would not be all that much, except for exception raising and handling. There it would be huge. Ultimately for PyStone, a couple of extra percents were gained.

This really was a point, where I felt, that Nuitka will make it or break. And for a long time, I honestly wasn't so sure, that I pull through. But I did.

Current Situation

The current pre-release is release quality. You should try it out, it's great.

  • There are many changes to Standalone mode. Due to changes in how constants are now created in the modules that uses them, instead of everything globally, the parallel compilation now works great. What previously took an hour with MSVC (the problem child, gcc was always relatively good), now takes minutes only.
  • The support for virtualenv's of all kinds seems to work on Windows, Linux, and MacOS, which all seem to have different kinds of codes.
  • The support for MacOS is now there. Thanks to a virtual server month donated to Jarrad Hope, I was able to iron issues out.
  • The final release will also work with standalone binaries created on Fedora 20 which got hard code rpaths removed on the factory git branch.

And yet, I am not yet releasing. In fact, I would like to ask you to give it a roll, and integrate test feedback.

Although more tests than ever are executed and pass, (e.g. the Mercurial test suite is now run each time I make a commit, and fully identically passes or fails the test suite with the current Mercurial code), there can never be enough.

The changes I made are the most intense ever, and definitely have potential for regressions. I am used to providing very high quality releases.

Also, I am working on the Buildbot instances to automate the production of performance graphs, which get updated fully automatically. I am working on updating the downloads page automatically for each release that gets made.

And generally, I am trying to improve my work flow, to make it easier to push out releases with less effort. Buildbot should drive the release process more completely. I am using the git flow to provide hot-fixes, and this should be even less painful in the future.

Open Points

With this release, presenting great progress, many things remain in an unfinished state.

  • The support for Python3.4 is not complete. Most things work, but some need more work. Specifically the changes to __class__ variable closure taking, need another major refactoring, this time on variable handling.

    Currently there are variables, closure variables, temp variables, and then temp variable references. The way they work is different. One way they work different, prevents a temp variable closure reference to carry a name, in that case -_class__, which would be needed for Python3.4, where that is suddenly necessary.

    With this done, the SSA code will be even easier to write, as temp variables and named variables will finally be fully unified.

  • The use of C++ classes is largely reduced now. But a few still remain, namely for local variables, closure variables, and temp variables that are explicit variables. They still use C++ classes, although changing that seems quite possible now, because at least for temporary variables, the class doesn't do anything in terms of code anymore.

    Removing these classes may well gain more performance.

  • Now that code generation can more easily make a difference, and SSA apparently is becoming reliable, it could be used to know that values must be value and to optimize checks away.

    Currently every variable access checks for "NULL", when it's part of an assign trace. Some optimizations exist for parameter variables without del on them, that do not use SSA.

    This could be expanded and made general, allowing for much less code to be generated (specifically avoiding error code, and release code for variables that cannot give an error).

  • The SSA has been found unreliable in some instances, due to bugs that I believe I found. We could attempt and forward propagate variable assignments to where they are used, eliminating variables, etc.

    This is a place, where a lot of performance can be gained. We really want to be there. And "C-ish" now makes this ever more attractive, despite the large delay in time it has caused.

  • The in-place assignment code for strings, where CPython can be way faster than current Nuitka, it bears a risk of getting it wrong. It is therefore pushed to a future release.

Other Things

For the website, I am relocating the virtual machine to a dedicated server rented for an increased price. This will allow to add a few more dynamic features, as the virtual machine was always too limited in RAM. It's more expensive, but I feel a better investment of my time.

As mentioned before, I am not going to conferences this year. Enjoy Europython, and consider having a Lightning talk about Nuitka. I will be there next year again.

Call for Help

  • Please test the latest release of Nuitka.
  • Please consider making a donation to support my work on Nuitka. I have continuous monthly costs of it, so it would be sweet if it's with all my time spent working on it, at least not a financial cost to me.
  • Please join the mailing list, and offer your help with tasks. Nuitka can seriously take more people developing, testing, reviewing, and quality checking it.

Final Words

So, there is this "C-ish" release 0.5.2 cooking. You are invited to help. Big, improvements are coming to Nuitka. Even after this next huge release, very important work is still open, but hope is to have this complete over the summer.

Yours, Kay

Comments

Try Finally Python Quiz    Posted:


When working on my Python compiler Nuitka, I often come across ridiculous language details of the Python language, and turn these into quizzes, for which I finally added a dedicated quiz tag.

Anyway, who can predict, what these will do to you:

def f():
    try:
        return 1
    finally:
        return 2

Will it return 1 or 2 ?

def f():
    try:
        1/0
    finally:
        return 2

Will this raise an ZeroDivisionError or return 2 ?

def f():
    while 1:
        try:
            continue
        finally:
            break

Is this an endless loop or does it return?

def f():
    while 1:
        try:
            break
        finally:
            continue

What about that? This one holds an inconsistency.

No solutions yet this time.

Comments

Nuitka Release 0.5.1    Posted:


This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler. Please see the page "What is Nuitka?" for an overview.

This release brings corrections and major improvements to how standalone mode performs. Much of it was contributed via patches and bug reports.

Bug Fixes

  • There was a crash when using next on a non-iterable. Fixed in 0.5.0.1 already.
  • Module names with special characters not allowed in C identifiers were not fully supported. Issue#118. Fixed in 0.5.0.1 already.
  • Name mangling for classes with leading underscores was not removing them from resulting attribute names. This broke at __slots__ with private attributes for such classes. Issue#119. Fixed in 0.5.0.1 already.
  • Standalone on Windows might need "cp430" encoding. Issue#120. Fixed in 0.5.0.2 already.
  • Standalone mode didn't work with lxml.etree due to lack of hard coded dependencies. When a shared library imports things, Nuitka cannot detect it easily.
  • Wasn't working on MacOS 64 bits due to using Linux 64 bits specific code. Issue#123. Fixed in 0.5.0.2 already.
  • On MinGW the constants blob was not properly linked on some installations, this is now done differently (see below).

New Features

  • Memory usages are now traced with --show-progress allowing us to trace where things go wrong.

New Optimization

  • Standalone mode now includes standard library as bytecode by default. This is workaround scalability issues with many constants from many modules. Future releases are going to undo it.
  • On Windows the constants blob is now stored as a resource, avoiding compilation via C code for MSVC as well. MinGW was changed to use the same code.

New Tests

  • Expanded test coverage for "standalone mode" demonstrating usage of "hex" encoding, PySide, and PyGtk packages.

Summary

This release is mostly an interim maintenance release for standalone. Major changes that provide optimization beyond that, termed "C-ish code generation" are delayed for future releases.

This release makes standalone practical which is an important point. Instead of hour long compilation, even for small programs, we are down to less than a minute.

The solution of the scalability issues with many constants from many modules will be top priority going forward. Since they are about how even single use constants are created all in one place, this will be easy, but as large changes are happening in "C-ish code generation", we are waiting for these to complete.

Comments

Not going to FOSDEM 2014    Posted:


So I submitted a talk for FOSDEM "Python has a compiler now". And it didn't get accepted. Quite a surprise to me, but likely mostly logical. These are the accepted talks and well, it surely didn't fit in, right.

My intent was to introduce Nuitka to the larger community. Not going to happen now, but maybe next year.

Clearly triggered by the rejection, I am questioning Europython 2014 in Berlin as a useful destination too. To me it seems, that code writing is the best way to create the community at this time anyway.

Comments

Nuitka Release 0.5.0    Posted:


This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler. Please see the page "What is Nuitka?" for an overview.

This release breaks interface compatibility, therefore the major version number change. Also "standalone mode" has seen significant improvements on both Windows, and Linux. Should work much better now.

But consider that this part of Nuitka is still in its infancy. As it is not the top priority of mine for Nuitka, which primarily is intended as an super compatible accelerator of Python, it will continue to evolve nearby.

There is also many new optimization based on structural improvements in the direction of actual SSA.

Bug Fixes

  • The "standalone mode" was not working on all Redhat, Fedora, and openSUSE platforms and gave warnings with older compilers. Fixed in 0.4.7.1 already.

  • The "standalone mode" was not including all useful encodings. Issue#116. Fixed in 0.4.7.2 already.

  • The "standalone mode" was defaulting to --python-flag=-S which disables the parsing of "site" module. That unfortunately made it necessary to reach some modules without modifying PYTHONPATH which conflicts with the "out-of-the-box" experience.

  • The "standalone mode" is now handling packages properly and generally working on Windows as well.

  • The syntax error of having an all catching except clause and then a more specific one wasn't causing a SyntaxError with Nuitka.

    try:
        something()
    except:
        somehandling():
    except TypeError:
        notallowed()
    
  • A corruption bug was identified, when re-raising exceptions, the top entry of the traceback was modified after usage. Depending on malloc this was potentially causing an endless loop when using it for output.

New Features

  • Windows: The "standalone" mode now properly detects used DLLs using Dependency Walker which it offers to download and extra for you.

    It is used as a replacement to ldd on Linux when building the binary, and as a replacement of strace on Linux when running the tests to check that nothing is loaded from the outside.

New Optimization

  • When iterating over list, set, this is now automatically lowered to tuples avoiding the mutable container types.

    So the following code is now equivalent:

    for x in [ a, b, c ]:
       ...
    
    # same as
    for x in (a, b, c):
       ...
    

    For constants, this is even more effective, because for mutable constants, no more is it necessary to make a copy.

  • Python2: The iteration of large range is now automatically lowered to xrange which is faster to loop over, and more memory efficient.

  • Added support for the xrange built-in.

  • The statement only expression optimization got generalized and now is capable of removing useless parts of operations, not only the whole thing when it has not side effects.

    [a,b]
    
    # same as
    a
    b
    

    This works for all container types.

    Another example is type built-in operation with single argument. When the result is not used, it need not be called.

    type(a)
    
    # same as
    a
    

    And another example is and is not have no effect of their own as well, therefore:

    a is b
    
    # same as
    a
    b
    
  • Added proper handling of conditional expression branches in SSA based optimization. So far these branches were ignored, which only acceptable for temporary variables as created by tree building, but not other variable types. This is preparatory for introducing SSA for local variables.

Organizational

  • The option --exe is now ignored and creating an executable is the default behavior of nuitka, a new option --module allows to produce extension modules.
  • The binary nuitka-python was removed, and is replaced by nuitka-run with now only implies --execute on top of what nuitka is.
  • Using dedicated Buildbot for continuous integration testing and release creation as well.
  • The Downloads now offers MSI files for Win64 as well.
  • Discontinued the support for cross compilation to Win32. That was too limited and the design choice is to have a running CPython instance of matching architecture at Nuitka compile time.

New Tests

  • Expanded test coverage for "standalone mode" demonstrating usage of "hex" encoding, and PySide package.

Summary

The "executable by default" interface change improves on the already high ease of use. The new optimization do not give all that much in terms of numbers, but are all signs of structural improvements, and it is steadily approaching the point, where the really interesting stuff will happen.

The progress for standalone mode is of course significant. It is still not quite there yet, but it is making quick progress now. This will attract a lot of attention hopefully.

As for optimization, the focus for it has shifted to making exception handlers work optimal by default (publish the exception to sys.exc_info() and create traceback only when necessary) and be based on standard branches. Removing special handling of exception handlers, will be the next big step. This release includes some correctness fixes stemming from that work already.

Comments

Re: About Python 3    Posted:


In Alex Gaynor's post there is just about everything right. I still want to add my take on it.

Python3 is a fork of the Python community, that has left the user base largely behind. After developing features very conservatively for a long time (from __future__ import division and stuff), where features were first available but not active by default, that whole "Python 3000" thing came up.

Misguided, after having maintained CPython on a level of excellence for such a long time, there was a sense of "finally we get to make free choices". I can understand that. And having witnessed Gnome 2.0.0, and KDE 4.0.0, I even start to believe that there is some kind of underlying law. Something that makes people want to start over.

That "5 years plan" Alex mentioned has failed, and everybody knows that without solving the GIL within the next 5 years, i.e. another incompatible Python change, it will likely become obsolete.

In terms of Python2.8, call it that way. Or have a 3.5 that has print statement, and then all kinds of incompatible changes to Python3 to make it behave sane bytes(7) needs to do what str(7) once it. That would be about from __past__ import .... I suppose.

I also had another idea, having a "python2" built-in module that carries a CPython2 interpreter and proxy objects for instances, where they talk to another with incompatible types (new bytes/unicode to old str).

Due to my work on that Python compiler that should have existed 20 years ago, I am familiar enough, to actually be able and create that kind of CPython2/CPython3 hybrid.

But the main problems with all of that are:

  1. CPython is developed by volunteers, and as such, they are neither obliged to do what we need, nor will they bend to any amount of posting. We need to get our acts together or it's not happening, and we are people who care about Python relevancy.

    There may not be nearly enough overlap of people capable and caring. And that would be a tremendous amount of work. Highly speculative, in the sense, that it may not see fruits.

  2. And then, when you got that sorted out, expect a hostile reaction from the core developers and/or PSF. Whatever it is, that you develop, you won't be able to call it Python 2.8, as they are going to hate it.

  3. And finally, as a course of action, that may even bring the complete downfall of Python as a community. The controversy associated is not for everybody, and we don't need a libreoffice/openoffice situation in Python, do we.

It's a pity, because clearly, for Nuitka there would be a bunch of patches, that I would like to make, that would make my life far easier, and even interpreted Python faster.

Comments