././@PaxHeader0000000000000000000000000000003300000000000010211 xustar0027 mtime=1758275202.512262 Nuitka-2.7.16/0000700000175100017520000000000015063223203016717 5ustar00nuitka-buildslavenuitka-buildslave././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/Changelog.rst0000644000175100017520000000035315063223176021364 0ustar00nuitka-buildslavenuitka-buildslave################## Nuitka Changelog ################## In this document, we track the per version changes and comments. This is now maintained separately at https://nuitka.net/changelog/Changelog.html please check it out from there. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/Developer_Manual.rst0000644000175100017520000045311215063223176022724 0ustar00nuitka-buildslavenuitka-buildslave######################### Nuitka Developer Manual ######################### The purpose of this Developer Manual is to present the current design of Nuitka, the project rules, and the motivations for choices made. It is intended to be a guide to the source code, and to give explanations that don't fit into the source code in comments form. It should be used as a reference for the process of planning and documenting decisions we made. Therefore we are e.g. presenting here the type inference plans before implementing them. And we update them as we proceed. It grows out of discussions and presentations made at conferences as well as private conversations or issue tracker. ************ Milestones ************ #. Feature parity with CPython, understand all the language construct and behave absolutely compatible. Feature parity has been reached for CPython 2.6 and 2.7. We do not target any older CPython release. For CPython 3 up to 3.13 it also has been reached. We do not target the older and practically unused CPython 3.0 to 3.3 releases. This milestone was reached. Dropping support for Python 2.6 is an option, should this prove to be any benefit. Currently it is not, as it extends the test coverage only. #. Create the most efficient native code from this. This means to be fast with the basic Python object handling. This milestone was reached, although of course, micro optimizations to this are happening all the time. #. Then do constant propagation, determine as many values and useful constraints as possible at compile time and create more efficient code. This milestone is considered almost reached. We continue to discover new things, but the infrastructure is there, and these are easy to add. #. Type inference, detect and special case the handling of strings, integers, lists in the program. This milestone is considered in progress. #. Add interfacing to C code, so Nuitka can turn a ``ctypes`` binding into an efficient binding as written with C. This milestone is planned only. #. Add hints module with a useful Python implementation that the compiler can use to learn about types from the programmer. This milestone is planned only. ***************** Version Numbers ***************** For Nuitka we use semantic versioning, initially with a leading zero still, once we pass release ``1.9``, the scheme will indicate the ``10`` through using ``2.0``. *************** Current State *************** Nuitka top level works like this: - ``nuitka.tree.Building`` outputs node tree - ``nuitka.optimization`` enhances it as best as it can - ``nuitka.finalization`` prepares the tree for code generation - ``nuitka.code_generation.CodeGeneration`` orchestrates the creation of code snippets - ``nuitka.code_generation.*Codes`` knows how specific code kinds are created - ``nuitka.MainControl`` keeps it all together This design is intended to last. Regarding types, the state is: - Types are always ``PyObject *``, and only a few C types, e.g. ``nuitka_bool`` and ``nuitka_void`` and more are coming. Even for objects, often it's know that things are e.g. really a ``PyTupleObject **``, but no C type is available for that yet. - There are a some specific use of types beyond "compile time constant", that are encoded in type and value shapes, which can be used to predict some operations, conditions, etc. if they raise, and result types they give. - In code generation, the supported C types are used, and sometimes we have specialized code generation, e.g. a binary operation that takes an ``int`` and a ``float`` and produces a ``float`` value. There will be fallbacks to less specific types. The expansion with more C types is currently in progress, and there will also be alternative C types, where e.g. ``PyObject *`` and ``C long`` are in an enum that indicates which value is valid, and where special code will be available that can avoid creating the ``PyObject **`` unless the later overflows. *************************************************** Setting up the Development Environment for Nuitka *************************************************** Currently there are very different kinds of files that we need support for. This is best addressed with an IDE. We cover here how to setup the most common one. Visual Studio Code ================== Download Visual Studio Code from here: https://code.visualstudio.com/download At this time, this is the recommended IDE for Linux and Windows. This is going to cover the plugins to install. Configuration is part of the ``.vscode`` in your Nuitka checkout. If you are not familiar with Eclipse, this is Free Software IDE,designed to be universally extended, and it truly is. There are plugins available for nearly everything. The extensions to be installed are part of the Visual Code recommendations in ``.vscode/extensions.json`` and you will be prompted about that and ought to install these. Eclipse / PyCharm ================= Don't use these anymore, we consider Visual Studio Code to be far superior for delivering a nice out of the box environment. ************************* Commit and Code Hygiene ************************* In Nuitka we have tools to auto format code, you can execute them manually, but it's probably best to execute them at commit time, to make sure when we share code, it's already well format, and to avoid noise doing cleanups. The kinds of changes also often cause unnecessary merge conflicts, while the auto format is designed to format code also in a way that it avoids merge conflicts in the normal case, e.g. by doing imports one item per line. In order to set up hooks, you need to execute these commands: .. code:: bash # Where python is the one you use with Nuitka, this then gets all # development requirements, can be full PATH. python -m pip install -r requirements-devel.txt python ./misc/install-git-hooks.py These commands will make sure that the ``autoformat-nuitka-source`` is run on every staged file content at the time you do the commit. For C files, it may complain unavailability of ``clang-format``, follow it's advice. You may call the above tool at all times, without arguments to format call Nuitka source code. Should you encounter problems with applying the changes to the checked out file, you can always execute it with ``COMMIT_UNCHECKED=1`` environment set. ********************* Coding Rules Python ********************* These rules should generally be adhered when working on Nuitka code. It's not library code and it's optimized for readability, and avoids all performance optimization for itself. Tool to format ============== There is a tool ``bin/autoformat-nuitka-source`` which is to apply automatic formatting to code as much as possible. It uses ``black`` (internally) for consistent code formatting. The imports are sorted with ``isort`` for proper order. The tool (mostly ``black`` and ``isort``) encodes all formatting rules, and makes the decisions for us. The idea being that we can focus on actual code and do not have to care as much about other things. It also deals with Windows new lines, trailing space, etc. and even sorts PyLint disable statements. Identifiers =========== Classes ------- Classes are camel case with leading upper case. Functions and methods are with leading verb in lower case, but also camel case. Variables and arguments are lower case with ``_`` as a separator. .. code:: python class SomeClass: def doSomething(some_parameter): some_var = ("foo", "bar") Base classes that are abstract have their name end with ``Base``, so that a meta class can use that convention, and readers immediately know, that it will not be instantiated like that. Functions --------- Function calls use keyword argument preferably. These are slower in CPython, but more readable: .. code:: python getSequenceCreationCode( sequence_kind=sequence_kind, element_identifiers=identifiers, context=context ) When the names don't add much value, sequential calls can be done: .. code:: python context.setLoopContinueTarget(handler_start_target) Here, ``setLoopContinueTarget`` will be so well known that the reader is expected to know the argument names and their meaning, but it would be still better to add them. But in this instance, the variable name already indicates that it is. Module/Package Names -------------------- Normal modules are named in camel case with leading upper case, because of their role as singleton classes. The difference between a module and a class is small enough and in the source code they are also used similarly. For the packages, no real code is allowed in their ``__init__.py`` and they must be lower case, like e.g. ``nuitka`` or ``codegen``. This is to distinguish them from the modules. Packages shall only be used to group things. In ``nuitka.code_generation`` the code generation packages are located, while the main interface is ``nuitka.code_generation.CodeGeneration`` and may then use most of the entries as local imports. There is no code in packages themselves. For programs, we use ``__main__`` package to carry the actual code. Names of modules should be plurals if they contain classes. Example is that a ``Nodes`` module that contains a ``Node`` class. Context Managers ---------------- Names for context manages start with ``with`` In order to easily recognize that something is to be used as a context manager, we follow a pattern of naming them ``withSomething``, to make that easily recognized. .. code:: python with withEnvironmentPathAdded(os.path.join(sys.prefix, "bin")): with withDirectoryChange(self.qt_datadir): ... This makes these easy to recognize even in their definition. Prefer list contractions over built-ins ======================================= This concerns ``map``, ``filter``, and ``apply``. Usage of these built-ins is highly discouraged within Nuitka source code. Using them is considered worth a warning by "PyLint" e.g. "Used built-in function 'map'". We should use list contractions instead, because they are more readable. List contractions are a generalization for all of them. We love readability and with Nuitka as a compiler, there won't be any performance difference at all. There are cases where a list contraction is faster because you can avoid to make a function call. And there may be cases, where map is faster, if a function must be called. These calls can be very expensive in CPython, and if you introduce a function, just for ``map``, then it might be slower. But of course, Nuitka is the project to free us from what is faster and to allow us to use what is more readable, so whatever is faster, we don't care. We make all options equally fast and let people choose. For Nuitka the choice is list contractions as these are more easily changed and readable. Look at this code examples from Python: .. code:: python class A: def getX(self): return 1 x = property(getX) class B(A): def getX(self): return 2 A().x == 1 # True B().x == 1 # True (!) This pretty much is what makes properties bad. One would hope ``B().x`` to be ``2``, but instead it's not changed. Because of the way properties take the functions and not members, and because they then are not part of the class, they cannot be overloaded without redeclaring them. Overloading is then not at all obvious anymore. Now imagine having a setter and only overloading the getter. How to update the property easily? So, that's not likable about them. And then we are also for clarity in these internal APIs too. Properties try and hide the fact that code needs to run and may do things. So let's not use them. For an external API you may exactly want to hide things, but internally that has no use, and in Nuitka, every API is internal API. One exception may be the ``hints`` module, which will gladly use such tricks for an easier write syntax. **************** Coding Rules C **************** For the static C parts, e.g. compiled types, helper codes, the ``clang-format`` from LLVM project is used, the tool ``autoformat-nuitka-source`` does this for us. We always have blocks for conditional statements to avoid typical mistakes made by adding a statement to a branch, forgetting to make it a block. ********************** The "git flow" model ********************** - The flow is used for releases and occasionally subsequent hot fixes. A few feature branches were used so far. It allows for quick delivery of fixes to both the stable and the development version, supported by a git plug-in, that can be installed via "apt-get install git-flow". - Stable (``main`` branch) The stable version, is expected to pass all the tests at all times and is fully supported. As soon as bugs are discovered, they are fixed as hot fixes, and then merged to develop by the "git flow" automatically. - Development (``develop`` branch) The future release, supposedly in almost ready for release state at nearly all times, but this is less strict. It is not officially supported, and may have problems and at times inconsistencies. Normally this branch is supposed to not be rebased. For severe problems it may be done though. - Factory (default feature branch) Code under construction. We publish commits there, that may not hold up in testing, and before it enters develop branch. Factory may have severe regressions frequently, and commits become **rebased all the time**, so do not base your patches on it, please prefer the ``develop`` branch for that, unless of course, it's about factory code itself. - Personal branches (jorj, orsiris, others as well) We are currently not using this, but it's an option. - Feature Branches We are not currently using these. They could be used for long lived changes that extend for multiple release cycles and are not ready yet. Currently we perform all changes in steps that can be included in releases or delay making those changes. ****************************** Nuitka "git/github" Workflow ****************************** - Forking and cloning You need to have git installed and GitHub account. Goto Nuitka repository and fork the repository. To clone it to your local machine execute the following your git bash: .. code:: bash git clone https://github.com/your-user-name/Nuitka.git cd Nuitka git remote add upstream https://github.com/Nuitka/Nuitka.git - Create a Branch .. code:: bash git checkout develop git pull --rebase upstream git checkout -b feature_branch If you are having merge conflicts while doing the previous step, then check out (DON'T FORGET TO SAVE YOUR CHANGES FIRST IF ANY): - In case you have an existing branch rebase it to develop .. code:: bash git fetch upstream git rebase upstream/develop Fix the merge conflicts if any and continue or skip commit if it is not your. Sometimes for important bug fixes, develop history gets rewritten. In that case, old and new commits will conflict during your rebase, and skipping is the best way to go. .. code:: bash git rebase --continue # not your commit: git rebase --skip If anything goes wrong while rebasing: .. code:: bash git rebase --abort - Making changes .. code:: bash git commit -a -m "Commit Message" git push -u origin # once, later always: git push ********************************** API Documentation and Guidelines ********************************** There is API documentation generated with ``doxygen``, available at `this location `__ . To ensure meaningful ``doxygen`` output, the following guidelines must be observed when creating or updating Python source: Use of Standard Python ``__doc__`` Strings ========================================== Every class and every method should be documented via the standard Python delimiters (``""" ... """``) in the usual way. Special ``doxygen`` Anatomy of ``__doc__`` ========================================== .. note:: We are replacing Doxygen with sphinx, this is all obsolete - Immediately after the leading ``"""``, and after 1 space on the same line, enter a brief description or title of the class or method. This must be 1 line and be followed by at least 1 empty line. - Depending on the item, choose from the following "sections" to describe what the item is and does. Each section name is coded on its own line, aligned with the leading ``"""`` and followed by a colon ":". Anything following the section, must start on a new line and be indented by 4 spaces relative to the section. Except for the first section (``Notes:``) after the title, sections need not be preceded by empty lines -- but it is good practice to still do that. - ``Notes:`` detailed description of the item, any length. May contain line breaks with each new line starting aligned with previous one. The text will automatically be joined across line breaks and be reformatted in the browser. If you describe details for a class, you can do so **without** using this section header and all formatting will still work fine. If you however omit the ``Notes:`` for methods, then the text will be interpreted **as code**, be shown in an ugly monospaced font, and no automatic line breaks will occur in the browser. - ``Args:`` positional arguments. Each argument then follows, starting on a new line and indented by 4 spaces. The argument name must be followed by a colon ``:`` or double hash ``--``, followed by a description of arbitrary length. The description can be separated by line breaks. - ``Kwargs:`` keyword arguments. Same rules as for args. - ``Returns:`` description of what will be returned if applicable (any length). - ``Yields:`` synonymous for ``Returns:``. - ``Raises:`` name any exceptions that may be raised. - ``Examples:`` specify any example code. .. code:: python def foo(p1, p2, kw1=None, kw2=None): """This is an example method. Notes: It does one or the other indispensable things based on some parameters and proudly returns a dictionary. Args: p1: parameter one p2: parameter two Kwargs: kw1: keyword one kw2: keyword two Returns: A dictionary calculated from the input. Raises: ValueError, IndexError Examples: >>> foo(1, 2, kw1=3, kw2=4) {'a': 4, 'b': 6} """ ********************* Checking the Source ********************* The static checking for errors is currently done with ``PyLint``. In the future, Nuitka itself will gain the ability to present its findings in a similar way, but this is not a priority, and we are not there yet. So, we currently use ``PyLint`` with options defined in a script. .. code:: bash ./bin/check-nuitka-with-pylint The above command is expected to give no warnings. It is also run on our CI and we will not merge branches that do not pass. ******************* Running the Tests ******************* This section describes how to run Nuitka tests. Running all Tests ================= The top level access to the tests is as simple as this: .. code:: bash ./tests/run-tests For fine grained control, it has the following options: .. code:: --skip-basic-tests The basic tests, execute these to check if Nuitka is healthy. Default is True. --skip-syntax-tests The syntax tests, execute these to check if Nuitka handles Syntax errors fine. Default is True. --skip-program-tests The programs tests, execute these to check if Nuitka handles programs, e.g. import recursions, etc. fine. Default is True. --skip-package-tests The packages tests, execute these to check if Nuitka handles packages, e.g. import recursions, etc. fine. Default is True. --skip-optimizations-tests The optimization tests, execute these to check if Nuitka does optimize certain constructs fully away. Default is True. --skip-standalone-tests The standalone tests, execute these to check if Nuitka standalone mode, e.g. not referring to outside, important 3rd library packages like PyQt fine. Default is True. --skip-reflection-test The reflection test compiles Nuitka with Nuitka, and then Nuitka with the compile Nuitka and compares the outputs. Default is True. --skip-cpython26-tests The standard CPython2.6 test suite. Execute this for all corner cases to be covered. With Python 2.7 this covers exception behavior quite well. Default is True. --skip-cpython27-tests The standard CPython2.7 test suite. Execute this for all corner cases to be covered. With Python 2.6 these are not run. Default is True. --skip-cpython32-tests The standard CPython3.2 test suite. Execute this for all corner cases to be covered. With Python 2.6 these are not run. Default is True. --skip-cpython33-tests The standard CPython3.3 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython34-tests The standard CPython3.4 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython35-tests The standard CPython3.5 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython36-tests The standard CPython3.6 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython37-tests The standard CPython3.7 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython38-tests The standard CPython3.8 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython39-tests The standard CPython3.9 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython310-tests The standard CPython3.10 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython311-tests The standard CPython3.11 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython312-tests The standard CPython3.12 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --skip-cpython313-tests The standard CPython3.13 test suite. Execute this for all corner cases to be covered. With Python 2.x these are not run. Default is True. --no-python2.6 Do not use Python 2.6 even if available on the system. Default is False. --no-python2.7 Do not use Python 2.7 even if available on the system. Default is False. --no-python3.4 Do not use Python 3.4 even if available on the system. Default is False. --no-python3.5 Do not use Python 3.5 even if available on the system. Default is False. --no-python3.6 Do not use Python 3.6 even if available on the system. Default is False. --no-python3.7 Do not use Python 3.7 even if available on the system. Default is False. --no-python3.8 Do not use Python 3.8 even if available on the system. Default is False. --no-python3.9 Do not use Python 3.9 even if available on the system. Default is False. --no-python3.10 Do not use Python 3.10 even if available on the system. Default is False. --no-python3.11 Do not use Python 3.11 even if available on the system. Default is False. --no-python3.12 Do not use Python 3.12 even if available on the system. Default is False. --no-python3.13 Do not use Python 3.13 even if available on the system. Default is False. --coverage Make a coverage analysis, that does not really check. Default is False. You will only run the CPython test suites, if you have the submodules of the Nuitka git repository checked out. Otherwise, these will be skipped with a warning that they are not available. The policy is generally, that ``./test/run-tests`` running and passing all the tests on Linux and Windows shall be considered sufficient for a release, but of course, depending on changes going on, that might have to be expanded. Basic Tests =========== You can run the "basic" tests like this: .. code:: bash ./tests/basics/run_all.py search These tests normally give sufficient coverage to assume that a change is correct, if these "basic" tests pass. The most important constructs and built-ins are exercised. To control the Python version used for testing, you can set the ``PYTHON`` environment variable to e.g. ``python3.5`` (can also be full path), or simply execute the ``run_all.py`` script directly with the intended version, as it is portable across all supported Python versions, and defaults testing with the Python version is run with. Syntax Tests ============ Then there are "syntax" tests, i.e. language constructs that need to give a syntax error. It sometimes so happens that Nuitka must do this itself, because the ``ast.parse`` doesn't see the problem and raises no ``SyntaxError`` of its own. These cases are then covered by tests to make sure they work as expected. Using the ``global`` statement on a function argument is an example of this. These tests make sure that the errors of Nuitka and CPython are totally the same for this: .. code:: bash ./tests/syntax/run_all.py search Program Tests ============= Then there are small "programs" tests, that e.g. exercise many kinds of import tricks and are designed to reveal problems with inter-module behavior. These can be run like this: .. code:: bash ./tests/programs/run_all.py search Generated Tests =============== There are tests, which are generated from Jinja2 templates. They aim at e.g. combining at types with operations, in-place or not, or large constants. These can be run like this: .. code:: bash ./tests/generated/run_all.py search Compile Nuitka with Nuitka ========================== And there is the "compile itself" or "reflected" test. This test makes Nuitka compile itself and compare the resulting C++ when running compiled to non-compiled, which helps to find in-determinism. The test compiles every module of Nuitka into an extension module and all of Nuitka into a single binary. That test case also gives good coverage of the ``import`` mechanisms, because Nuitka uses a lot of packages and imports between them. .. code:: bash ./tests/reflected/compile_itself.py ********************* Internal/Plugin API ********************* The documentation from the source code for both the Python and the C parts are published as `Nuitka API `__ and arguably in a relatively bad shape as we started generating those with Doxygen only relatively late. .. code:: bash doxygen ./doc/Doxyfile xdg-open html Improvements have already been implemented for plugins: The plugin base class defined in ``PluginBase.py`` (which is used as a template for all plugins) is fully documented in Doxygen now. The same is true for the recently added standard plugins ``NumpyPlugin.py`` and ``TkinterPlugin.py``. These will be uploaded very soon. Going forward, this will also happen for the remaining standard plugins. Please find `here `__ a detailed description of how to write your own plugin. To learn about plugin option specification consult `this document `__. ********************************* Working with the CPython suites ********************************* Resetting CPython suites ======================== The CPython test suites are different branches of the same submodule. When you update your git checkout, they will frequently become detached. In this case, simply execute this command: .. code:: bash git submodule foreach 'git fetch && git checkout $(basename $(pwd)) && \ git reset --hard origin/$(basename $(pwd))' Added new CPython suites ======================== When adding a test suite, for a new version, proceed like this, of course while adapting of course the names. These are the commands used for adding CPython313 based on the CPython312 branch. .. code:: bash # Switch to a new branch. git checkout CPython312 git branch CPython313 git checkout CPython313 # Delete all but root commit git reset --hard `git log --root --oneline --reverse | head -1 | cut -d' ' -f1` # Switch test data to upstream ones. rm -rf test cp -r ~/repos/Nuitka-references/final/Python-3.13.0/Lib/test test git add test # Update commit message to mention proper Python version. git commit --amend -m "Initial commit of Python tests as in 3.13.0" # Push to github, setting upstream for branch. git push -u # Cherry pick the removal commits from previous branches. git log origin/CPython312 --reverse --oneline | grep ' Removed' | cut -d' ' -f1 | xargs git cherry-pick # When being prompted for merge conflicts with the deleted files: git status | sed -n 's/deleted by them://p' | xargs git rm --ignore-unmatch x ; git cherry-pick --continue # Push to github, this is useful. git push # Cherry pick the first commit of 'run_all.py', the copy it from the last state, and amend the commits. git log --reverse origin/CPython312 --oneline -- run_all.py | head -1 | cut -d' ' -f1 | xargs git cherry-pick git checkout origin/CPython312 -- run_all.py chmod +x run_all.py sed -i -e 's#python3.12#python3.13#' run_all.py git commit --amend --no-edit run_all.py # Same for 'update_doctest_generated.py' git log --reverse origin/CPython312 --oneline -- update_doctest_generated.py | head -1 | cut -d' ' -f1 | xargs git cherry-pick git checkout origin/CPython312 -- update_doctest_generated.py chmod +x update_doctest_generated.py sed -i -e 's#python3.12#python3.13#' update_doctest_generated.py git commit --amend --no-edit update_doctest_generated.py # Same for .gitignore git log --reverse origin/CPython312 --oneline -- .gitignore | head -1 | cut -d' ' -f1 | xargs git cherry-pick git checkout origin/CPython312 -- .gitignore git commit --amend --no-edit .gitignore # Now cherry-pick all commits of test support, these disable network, audio, GUI, random filenames and more # and are crucial for deterministic outputs and non-reliance on outside stuff. git log --reverse origin/CPython312 --oneline -- test/support/__init__.py | tail -n +2 | cut -d' ' -f1 | xargs git cherry-pick git push ********************* Design Descriptions ********************* These should be a lot more and contain graphics from presentations given. It will be filled in, but not now. Nuitka Logo =========== The logo was submitted by "dr. Equivalent". It's source is contained in ``doc/Logo`` where 3 variants of the logo in SVG are placed. - Symbol only (symbol) .. code:: rest .. image:: doc/images/Nuitka-Logo-Symbol.png :alt: Nuitka Logo - Text next to symbol (horizontal) .. code:: rest .. image:: doc/images/Nuitka-Logo-Horizontal.png :alt: Nuitka Logo - Text beneath symbol (vertical) .. code:: rest .. image:: doc/images/Nuitka-Logo-Vertical.png :alt: Nuitka Logo From these logos, PNG images, and "favicons", and are derived. The exact ImageMagick commands are in ``nuitka/tools/release/Documentation``, but are not executed each time, the commands are also replicated here: .. code:: bash convert -background none doc/Logo/Nuitka-Logo-Symbol.svg doc/images/Nuitka-Logo-Symbol.png convert -background none doc/Logo/Nuitka-Logo-Vertical.svg doc/images/Nuitka-Logo-Vertical.png convert -background none doc/Logo/Nuitka-Logo-Horizontal.svg doc/images/Nuitka-Logo-Horizontal.png Choice of the Target Language ============================= - Choosing the target language was important decision. factors were: - The portability of Nuitka is decided here - How difficult is it to generate the code? - Does the Python C-API have bindings? - Is that language known? - Does the language aid to find bugs? The *decision for C11* is ultimately one for portability, general knowledge of the language and for control over created code, e.g. being able to edit and try that quickly. The current status is to use pure C11. All code compiles as C11, and also in terms of workaround to missing compiler support as C++03. This is mostly needed, because MSVC does not support C. Naturally we are not using any C++ features, just the allowances of C++ features that made it into C11, which is e.g. allowing late definitions of variables. Use of Scons internally ======================= Nuitka does not involve Scons in its user interface at all; Scons is purely used internally. Nuitka itself, being pure Python, will run without any build process just fine. Nuitka simply prepares ``.build`` folders with lots of files and tasks scons to execute the final build, after which Nuitka again will take control and do more work as necessary. .. note:: When we speak of "standalone" mode, this is handled outside of Scons, and after it, creating the ".dist" folder. This is done in ``nuitka.MainControl`` module. For interfacing to Scons, there is the module ``nuitka.build.SconsInterface`` that will support calling ``scons`` - potentially from one of two inline copies (one for before / one for Python 3.5 or later). These are mainly used on Windows or when using source releases - and passing arguments to it. These arguments are passed as ``key=value``, and decoded in the scons file of Nuitka. The scons file is named ``SingleExe.scons`` for lack of better name. It's really wrong now, but we have yet to find a better name. It once expressed the intention to be used to create executables, but the same works for modules too, as in terms of building, and to Scons, things really are the same. The scons file supports operation in multiple modes for many things, and modules is just one of them. It runs outside of Nuitka process scope, even with a different Python version potentially, so all the information must be passed on the command line. What follows is the (lengthy) list of arguments that the scons file processes: - ``source_dir`` Where is the generated C source code. Scons will just compile everything it finds there. No list of files is passed, but instead this directory is being scanned. - ``nuitka_src`` Where do the include files and static C parts of Nuitka live. These provide e.g. the implementation of compiled function, generators, and other helper codes, this will point to where ``nuitka.build`` package lives normally. - ``module_mode`` Build a module instead of a program. - ``result_base`` This is not a full name, merely the basename for the result to be produced, but with path included, and the suffix comes from module or executable mode. - ``debug_mode`` Enable debug mode, which is a mode, where Nuitka tries to help identify errors in itself, and will generate less optimal code. This also asks for warnings, and makes the build fail if there are any. Scons will pass different compiler options in this case. - ``python_debug`` Compile and link against Python debug mode, which does assertions and extra checks, to identify errors, mostly related to reference counting. May make the build fail, if no debug build library of CPython is available. On Windows it is possible to install it for CPython3.5 or higher. - ``full_compat_mode`` Full compatibility, even where it's stupid, i.e. do not provide information, even if available, in order to assert maximum compatibility. Intended to control the level of compatibility to absurd. - ``experimental_mode`` Do things that are not yet accepted to be safe. - ``lto_mode`` Make use of link time optimization of gcc compiler if available and known good with the compiler in question. So far, this was not found to make major differences. - ``disable_console`` Windows subsystem mode: Disable console for windows builds. - ``unstripped_mode`` Unstripped mode: Do not remove debug symbols. - ``clang_mode`` Clang compiler mode, default on macOS X and FreeBSD, optional on Linux. - ``mingw_mode`` MinGW compiler mode, optional and useful on Windows only. - ``standalone_mode`` Building a standalone distribution for the binary. - ``show_scons`` Show scons mode, output information about Scons operation. This will e.g. also output the actual compiler used, output from compilation process, and generally debug information relating to be build process. - ``python_prefix`` Home of Python to be compiled against, used to locate headers and libraries. - ``target_arch`` Target architecture to build. Only meaningful on Windows. - ``python_version`` The major version of Python built against. - ``abiflags`` The flags needed for the Python ABI chosen. Might be necessary to find the folders for Python installations on some systems. - ``icon_path`` The icon to use for Windows programs if given. Locating Modules and Packages ============================= The search for modules used is driven by ``nuitka.importing.Importing`` module. - Quoting the ``nuitka.importing.Importing`` documentation: Locating modules and package source on disk. The actual import of a module would already execute code that changes things. Imagine a module that does ``os.system()``, it would be done during compilation. People often connect to databases, and these kind of things, at import time. Therefore CPython exhibits the interfaces in an ``imp`` module in standard library, which one can use those to know ahead of time, what file import would load. For us unfortunately there is nothing in CPython that is easily accessible and gives us this functionality for packages and search paths exactly like CPython does, so we implement here a multi step search process that is compatible. This approach is much safer of course and there is no loss. To determine if it's from the standard library, one can abuse the attribute ``__file__`` of the ``os`` module like it's done in ``isStandardLibraryPath`` of this module. End quoting the ``nuitka.importing.Importing`` documentation. - Role This module serves the recursion into modules and analysis if a module is a known one. It will give warnings for modules attempted to be located, but not found. These warnings are controlled by a while list inside the module. The decision making and caching are located in the ``nuitka.tree`` package, in modules ``nuitka.tree.Recursion`` and ``nuitka.tree.ImportCache``. Each module is only considered once (then cached), and we need to obey lots of user choices, e.g. to compile a standard library or not. Hooking for module ``import`` process ===================================== Currently, in generated code, for every ``import`` a normal ``__import__()`` built-in call is executed. The ``nuitka/build/static_src/MetaPathBasedLoader.c`` file provides the implementation of a ``sys.meta_path`` hook. This meta path based importer allows us to have the Nuitka provided module imported even when imported by non-compiled code. .. note:: Of course, it would make sense to compile time detect which module it is that is being imported and then to make it directly. At this time, we don't have this inter-module optimization yet, mid-term it should become easy to add. Supporting ``__class__`` of Python3 =================================== In Python3 the handling of ``__class__`` and ``super`` is different from Python2. It used to be a normal variable, and now the following things have changed. - The use of the ``super`` variable name triggers the addition of a closure variable ``__class__``, as can be witnessed by the following code: .. code:: python class X: def f1(self): print(locals()) def f2(self): print(locals()) super # Just using the name, not even calling it. x = X() x.f1() x.f2() Output is: .. code:: {'self': <__main__.X object at 0x7f1773762390>''} {'self': <__main__.X object at 0x7f1773762390>, '__class__': } - This value of ``__class__`` is also available in the child functions. - The parser marks up code objects usage of "super". It doesn't have to be a call, it can also be a local variable. If the ``super`` built-in is assigned to another name and that is used without arguments, it won't work unless ``__class__`` is taken as a closure variable. - As can be seen in the CPython3 code, the closure value is added after the class creation is performed. - It appears, that only functions locally defined to the class are affected and take the closure. This left Nuitka with the strange problem, of how to emulate that. The solution is this: - Under Python3, usage of ``__class__`` as a reference in a child function body is mandatory. It remains that way until all variable names have been resolved. - When recognizing calls to ``super`` without arguments, make the arguments into variable reference to ``__class__`` and potentially ``self`` (actually first argument name). - After all variables have been known, and no suspicious unresolved calls to anything named ``super`` are down, then unused references are optimized away by the normal unused closure variable. - Class dictionary definitions are added. These are special direct function calls, ready to propagate also "bases" and "metaclass" values, which need to be calculated outside. The function bodies used for classes will automatically store ``__class__`` as a shared local variable, if anything uses it. And if it's not assigned by user code, it doesn't show up in the "locals()" used for dictionary creation. Existing ``__class__`` local variable values are in fact provided as closure, and overridden with the built class , but they should be used for the closure giving, before the class is finished. So ``__class__`` will be local variable of the class body, until the class is built, then it will be the ``__class__`` itself. Frame Stack =========== In Python, every function, class, and module has a frame. It is created when the scope is entered, and there is a stack of these at run time, which becomes visible in tracebacks in case of exceptions. The choice of Nuitka is to make this an explicit element of the node tree, that are as such subject to optimization. In cases, where they are not needed, they may be removed. Consider the following code. .. code:: python def f(): if someNotRaisingCall(): return somePotentiallyRaisingCall() else: return None In this example, the frame is not needed for all the code, because the condition checked wouldn't possibly raise at all. The idea is the make the frame guard explicit and then to reduce its scope whenever possible. So we start out with code like this one: .. code:: python def f(): with frame_guard("f"): if someNotRaisingCall(): return somePotentiallyRaisingCall() else: return None This is to be optimized into: .. code:: python def f(): if someNotRaisingCall(): with frame_guard("f"): return somePotentiallyRaisingCall() else: return None Notice how the frame guard taking is limited and may be avoided, or in best cases, it might be removed completely. Also this will play a role when in-lining function. The frame stack entry will then be automatically preserved without extra care. .. note:: In the actual code, ``nuitka.nodes.FrameNodes.StatementsFrame`` is represents this as a set of statements to be guarded by a frame presence. Parameter Parsing ================= The parsing of parameters is very convoluted in Python, and doing it in a compatible way is not that easy. This is a description of the required process, for an easier overview. Input ----- The input is an argument ``tuple`` (the type is fixed), which contains the positional arguments, and potentially an argument ``dict`` (type is fixed as well, but could also be ``NULL``, indicating that there are no keyword arguments. Keyword dictionary ------------------ The keyword argument dictionary is checked first. Anything in there, that cannot be associated, either raise an error, or is added to a potentially given star dict argument. So there are two major cases. - No star dict argument: Iterate over dictionary, and assign or raise errors. This check covers extra arguments given. - With star dict argument: Iterate over dictionary, and assign or raise errors. Interesting case for optimization are no positional arguments, then no check is needed, and the keyword argument dictionary could be used as the star argument. Should it change, a copy is needed though. What's noteworthy here, is that in comparison to the keywords, we can hope that they are the same value as we use. The interning of strings increases chances for non-compiled code to do that, esp. for short names. We then can do a simple ``is`` comparison and only fall back to real string ``==`` comparisons, after all of these failed. That means more code, but also a lot faster code in the positive case. Argument tuple -------------- After this completed, the argument tuple is up for processing. The first thing it needs to do is to check if it's too many of them, and then to complain. For arguments in Python2, there is the possibility of them being nested, in which case they cannot be provided in the keyword dictionary, and merely should get picked from the argument tuple. Otherwise, the length of the argument tuple should be checked against its position and if possible, values should be taken from there. If it's already set (from the keyword dictionary), raise an error instead. SSA form for Nuitka =================== The SSA form is critical to how optimization works. The so called trace collections builds up traces. These are facts about how this works: - Assignments draw from a counter unique for the variable, which becomes the variable version. This happens during tree building phase. - References are associated with the version of the variable active. This can be a merge of branches. Trace collection does do that and provides nodes with the currently active trace for a variable. The data structures used for trace collection need to be relatively compact as the trace information can become easily much more data than the program itself. Every trace collection has these: - variable_actives Dictionary, where per "variable" the currently used version is. Used to track situations changes in branches. This is the main input for merge process. - variable_traces Dictionary, where "variable" and "version" form the key. The values are objects with or without an assignment, and a list of usages, which starts out empty. These objects have usages appended to them. In "onVariableSet", a new version is allocated, which gives a new object for the dictionary, with an empty usages list, because each write starts a new version. In "onVariableUsage" the version is detected from the current version. It may be not set yet, which means, it's a read of an undefined value (local variable, not a parameter name), or unknown in case of global variable. These objects may be told that their value has escaped. This should influence the value friend they attached to the initial assignment. Each usage may have a current value friend state that is different. When merging branches of conditional statements, the merge shall apply as follows: - Branches have their own collection Thee have potentially deviating sets of ``variable_actives``. These are children of an outer collections. - Case a) One branch only. For that branch a collection is performed. As usual new assignments generate a new version making it "active", references then related to these "active" versions. Then, when the branch is merged, for all "active" variables, it is considered, if that is a change related to before the branch. If it's not the same, a merge trace with the branch condition is created with the one active in the collection before that statement. - Case b) Two branches. When there are two branches, they both as are treated as above, except for the merge. When merging, a difference in active variables between the two branches creates the merge trace. .. note:: For conditional expressions, there are always only two branches. Even if you think you have more than one branch, you do not. It's always nested branches, already when it comes out of the ``ast`` parser. Trace structure, there are different kinds of traces. - Initial write of the version There may be an initial write for each version. It can only occur at the start of the scope, but not later, and there is only one. This might be known to be "initialized" (parameter variables of functions are like that) or "uninitialized", or "unknown". - Merge of other one or two other versions This combines two or more previous versions. In cases of loop exits or entries, there are multiple branches to combine potentially. These branches can have vastly different properties. - Becoming unknown. When control flow escapes, e.g. for a module variable, any write can occur to it, and it's value cannot be trusted to be unchanged. These are then traced as unknown. All traces have a base class ``ValueTraceBase`` which provides the interface to query facts about the state of a variable in that trace. It's e.g. of some interest, if a variable must have a value or must not. This allows to e.g. omit checks, know what exceptions might raise. Loop SSA ======== For loops we have the addition difficulty that we need would need to look ahead what types a variable has at loop exit, but that is a cyclic dependency. Our solution is to consider the variable types at loop entry. When these change, we drop all gained information from inside the loop. We may e.g. think that a variable is a ``int`` or ``float``, but later recognize that it can only be a float. Derivations from ``int`` must be discarded, and the loop analysis restarted. Then during the loop, we assign an incomplete loop trace shape to the variable, which e.g. says it was an ``int`` initially and additional type shapes, e.g. ``int or long`` are then derived. If at the end of the loop, a type produced no new types, we know we are finished and mark the trace as a complete loop trace. If it is not, and next time, we have the same initial types, we add the ones derived from this to the starting values, and see if this gives more types. Python Slots in Optimization ============================ Basic Slot Idea --------------- For almost all the operations in Python, a form of overloading is available. That is what makes it so powerful. So when you write an expression like this one: .. code:: python 1.0 + something This something will not just blindly work when it's a float, but go through a slot mechanism, which then can be overloaded. .. code:: python class SomeStrangeFloat: def __float__(self): return 3.14 something = SomeStrangeFloat() # ... 1.0 + float(something) // 4.140000000000001 Here it is the case, that this is used by user code, but more often this is used internally. Not all types have all slots, e.g. ``list`` does not have ``__float__`` and therefore will refuse an addition to a ``float`` value, based on that. Another slot is working here, that we didn't mention yet, and that is ``__add__`` which for some times will be these kinds of conversions or it will not do that kind of thing, e.g. something do hard checks, which is why this fails to work: .. code:: python [] + () As a deliberate choice, there is no ``__list__`` slot used. The Python designers are aiming at solving many things with slots, but they also accept limitations. There are many slots that are frequently used, most often behind your back (``__iter__``, ``__next__``, ``__lt__``, etc.). The list is large, and tends to grow with Python releases, but it is not endless. Representation in Nuitka ------------------------ So a slot in Nuitka typically has an owning node. We use ``__len__`` as an example here. In the ``computeExpression`` the ``len`` node named ``ExpressionBuiltinLen`` has to defer the decision what it computes to its argument. .. code:: python def computeExpression(self, trace_collection): return self.subnode_value.computeExpressionLen( len_node=self, trace_collection=trace_collection ) That decision then, in the absence of any type knowledge, must be done absolutely carefully and conservative, as could see anything executing here. That examples this code in ``ExpressionBase`` which every expression by default uses: .. code:: python def computeExpressionLen(self, len_node, trace_collection): shape = self.getValueShape() has_len = shape.hasShapeSlotLen() if has_len is False: return makeRaiseTypeErrorExceptionReplacementFromTemplateAndValue( template="object of type '%s' has no len()", operation="len", original_node=len_node, value_node=self, ) elif has_len is True: iter_length = self.getIterationLength() if iter_length is not None: from .ConstantRefNodes import makeConstantRefNode result = makeConstantRefNode( constant=int(iter_length), # make sure to downcast long source_ref=len_node.getSourceReference(), ) result = wrapExpressionWithNodeSideEffects(new_node=result, old_node=self) return ( result, "new_constant", "Predicted 'len' result from value shape.", ) self.onContentEscapes(trace_collection) # Any code could be run, note that. trace_collection.onControlFlowEscape(self) # Any exception may be raised. trace_collection.onExceptionRaiseExit(BaseException) return len_node, None, None Notice how by default, known ``__len__`` but unpredictable or even unknown if a ``__len__`` slot is there, the code indicates that its contents and the control flow escapes (could change things behind out back) and any exception could happen. Other expressions can know better, e.g. for compile time constants we can be a whole lot more certain: .. code:: python def computeExpressionLen(self, len_node, trace_collection): return trace_collection.getCompileTimeComputationResult( node=len_node, computation=lambda: len(self.getCompileTimeConstant()), description="""Compile time constant len value pre-computed.""", ) In this case, we are using a function that will produce a concrete value or the exception that the ``computation`` function raised. In this case, we can let the Python interpreter that runs Nuitka do all the hard work. This lives in ``CompileTimeConstantExpressionBase`` and is the base for all kinds of constant values, or even built-in references like the name ``len`` itself and would be used in case of doing ``len(len)`` which obviously gives an exception. Other overloads do not currently exist in Nuitka, but through the iteration length, most cases could be addressed, e.g. ``list`` nodes typical know their element counts. The C side ========== When a slot is not optimized away at compile time however, we need to generate actual code for it. We figure out what this could be by looking at the original CPython implementation. .. code:: C PyObject *builtin_len(PyObject *self, PyObject *v) { Py_ssize_t res; res = PyObject_Size(v); if (res < 0 && PyErr_Occurred()) return NULL; return PyInt_FromSsize_t(res); } We find a pointer to ``PyObject_Size`` which is a generic Python C/API function used in the ``builtin_len`` implementation: .. code:: C Py_ssize_t PyObject_Size(PyObject *o) { PySequenceMethods *m; if (o == NULL) { null_error(); return -1; } m = o->ob_type->tp_as_sequence; if (m && m->sq_length) return m->sq_length(o); return PyMapping_Size(o); } On the C level, every Python object (the ``PyObject *``) as a type named ``ob_type`` and most of its elements are slots. Sometimes they form a group, here ``tp_as_sequence`` and then it may or may not contain a function. This one is tried in preference. Then, if that fails, next up the mapping size is tried. .. code:: C Py_ssize_t PyMapping_Size(PyObject *o) { PyMappingMethods *m; if (o == NULL) { null_error(); return -1; } m = o->ob_type->tp_as_mapping; if (m && m->mp_length) return m->mp_length(o); type_error("object of type '%.200s' has no len()", o); return -1; } This is the same principle, except with ``tp_as_mapping`` and ``mp_length`` used. So from this, we can tell how ``len`` gets at what could be a Python class ``__len__`` or other built-in types. In principle, every slot needs to be dealt with in Nuitka, and it is assumed that currently all slots are supported on at least a very defensive level, to avoid unnoticed escapes of control flow. Built-in call optimization ========================== For calls to built-in names, there is typically a function in Python that delegates to the type constructor (e.g. when we talk about ``int`` that just creates an object passing the arguments of the call) or its own special implementation as we saw with the ``len``. For each built-in called, we have a specialized node, that presents to optimization the actions of the built-in. What are the impact, what are the results. We have seen the resulting example for ``len`` above, but how do we get there. In Python, built-in names are used only if there is no module level variable of the name, and of course no local variable of that name. Therefore, optimization of a built-in name is only done if it turns out the actually assigned in other code, and then when the call comes, arguments are checked and a relatively static node is created. Code Generation towards C ========================= Currently, Nuitka uses Pure C and no C++ patterns at all. The use of C11 requires on some platforms to compile the C11 using a C++ compiler, which works relatively well, but also limits the amount of C11 that can be used. Exceptions ---------- To handle and work with exceptions, every construct that can raise has either a ``bool`` or ``int`` return code or ``PyObject *`` with ``NULL`` return value. This is very much in line with that the Python C-API does. Every helper function that contains code that might raise needs these variables. After a failed call, our variant of ``PyErr_Fetch`` called ``FETCH_ERROR_OCCURRED_STATE`` must be used to catch the defined error, unless some quick exception cases apply. The quick exception means, ``NULL`` return from C-API without a set exception means e.g. ``StopIteration``. As an optimization, functions that raise exceptions, but are known not to do so, for whatever reason, could only be asserted to not do so. Statement Temporary Variables ----------------------------- For statements and larger constructs the context object track temporary values, that represent references. For some, these should be released at the end of the statement, or they represent a leak. The larger scope temporary variables, are tracked in the function or module context, where they are supposed to have explicit ``del`` to release their references. Local Variables Storage ----------------------- Closure variables taken are to be released when the function object is later destroyed. For in-lined calls, variables are just passed, and it does not become an issue to release anything. For function exit, owned variables, local or shared to other functions, must be released. This cannot be a ``del`` operation, as it also involves setting a value, which would be wrong for shared variables (and wasteful to local variables, as that would be its last usage). Therefore we need a special operation that simply releases the reference to the cell or object variable. Exit Targets ------------ Each error or other exit releases statement temporary values and then executes a ``goto`` to the exit target. These targets need to be setup. The ``try``/``except`` will e.g. catch error exits. Other exits are ``continue``, ``break``, and ``return`` exits. They all work alike. Generally, the exits stack of with constructs that need to register themselves for some exit types. A loop e.g. registers the ``continue`` exit, and a contained ``try``/``finally`` too, so it can execute the final code should it be needed. Frames ------ Frames are containers for variable declarations and cleanups. As such, frames provide error exits and success exits, which remove the frame from the frame stack, and then proceed to the parent exit. With the use of non ``PyObject **`` C types, but frame exception exits, the need to convert those types becomes apparent. Exceptions should still resolve the C version. When using different C types at frame exception exits, there is a need to trace the active type, so it can be used in the correct form. Abortive Statements ------------------- The way ``try``/``finally`` is handled, copies of the ``finally`` block are made, and optimized independently for each abort method. The ones there are of course, ``return``, ``continue``, and ``break``, but also implicit and explicit ``raise`` of an exception. Code trailing an abortive statement can be discarded, and the control flow will follow these "exits". Constant Preparation ==================== Early versions of Nuitka, created all constants for the whole program for ready access to generated code, before the program launches. It did so in a single file, but that approach didn't scale well. Problems were - Even unused code contributed to start-up time, this can become a lot for large programs, especially in standalone mode. - The massive amount of constant creation codes gave backend C compilers a much harder time than necessary to analyse it all at once. The current approach is as follows. Code generation detects constants used in only one module, and declared ``static`` there, if the module is the only user, or ``extern`` if it is not. Some values are forced to be global, as they are used pre-main or in helpers. These ``extern`` values are globally created before anything is used. The ``static`` values are created when the module is loaded, i.e. something did import it. We trace used constants per module, and for nested ones, we also associate them. The global constants code is special in that it can only use ``static`` for nested values it exclusively uses, and has to export values that others use. Language Conversions to make things simpler =========================================== There are some cases, where the Python language has things that can in fact be expressed in a simpler or more general way, and where we choose to do that at either tree building or optimization time. The ``assert`` statement ------------------------ The ``assert`` statement is a special statement in Python, allowed by the syntax. It has two forms, with and without a second argument. The later is probably less known, as is the fact that raise statements can have multiple arguments too. The handling in Nuitka is: .. code:: python assert value # Absolutely the same as: if not value: raise AssertionError .. code:: python assert value, raise_arg # Absolutely the same as: if not value: raise AssertionError(raise_arg) This makes assertions absolutely the same as a raise exception in a conditional statement. This transformation is performed at tree building already, so Nuitka never knows about ``assert`` as an element and standard optimizations apply. If e.g. the truth value of the assertion can be predicted, the conditional statement will have the branch statically executed or removed. The "comparison chain" expressions ---------------------------------- In Nuitka we have the concept of an outline, and therefore we can make the following re-formulation instead: .. code:: python a < b() > c < d def _comparison_chain(): # So called "outline" function tmp_a = a tmp_b = b() tmp = tmp_a < tmp_b if not tmp: return tmp del tmp_a tmp_c = c tmp = tmp_b > tmp_c if not tmp: return tmp del tmp_b return tmp_c < d _comparison_chain() This transformation is performed at tree building already. The temporary variables keep the value for the use of the same expression. Only the last expression needs no temporary variable to keep it. What we got from this, is making the checks of the comparison chain explicit and comparisons in Nuitka to be internally always about two operands only. The ``execfile`` built-in ------------------------- Handling is: .. code:: python execfile(filename) # Basically the same as: exec(compile(open(filename).read()), filename, "exec") .. note:: This allows optimizations to discover the file opening nature easily and apply file embedding or whatever we will have there one day. This transformation is performed when the ``execfile`` built-in is detected as such during optimization. Generator expressions with ``yield`` ------------------------------------ These are converted at tree building time into a generator function body that yields from the iterator given, which is the put into a for loop to iterate, created a lambda function of and then called with the first iterator. That eliminates the generator expression for this case. It's a bizarre construct and with this trick needs no special code generation. This is a complex example, demonstrating multiple cases of yield in unexpected cases: .. code:: python x = ((yield i) for i in (1, 2) if not (yield)) # Basically the same as: def x(): for i in (1, 2): if not (yield): yield (yield i) Function Decorators ------------------- When one learns about decorators, you see that: .. code:: python @decorator def function(): pass # Is basically the same as: def function(): pass function = decorator(function) The only difference is the assignment to function. In the ``@decorator`` case, if the decorator fails with an exception, the name ``function`` is not assigned yet, but kept in a temporary variable. Therefore in Nuitka this assignment is more similar to that of a lambda expression, where the assignment to the name is only at the end, which also has the extra benefit of not treating real function and lambda functions any different. This removes the need for optimization and code generation to support decorators at all. And it should make the two variants optimize equally well. Functions nested arguments -------------------------- Nested arguments are a Python2 only feature supported by Nuitka. Consider this example: .. code:: python def function(a, (b, c)): return a, b, c We solve this, by kind of wrapping the function with another function that does the unpacking and gives the errors that come from this: .. code:: python def function(a, _1): def _tmp(a, b, c): return a, b, c a, b = _1 return _tmp(a, b, c) The ``.1`` is the variable name used by CPython internally, and actually works if you use keyword arguments via star dictionary. So this is very compatible and actually the right kind of re-formulation, but it removes the need from the code that does parameter parsing to deal with these. Obviously, there is no frame for ``_tmp``, just one for ``function`` and we do not use local variables, but temporary functions. In-place Assignments -------------------- In-place assignments are re-formulated to an expression using temporary variables. These are not as much a reformulation of ``+=`` to ``+``, but instead one which makes it explicit that the assign target may change its value. .. code:: python a += b .. code:: python _tmp = a.__iadd__(b) if a is not _tmp: a = _tmp Using ``__iadd__`` here to express that for the ``+``, the in-place variant ``iadd`` is used instead. The ``is`` check may be optimized away depending on type and value knowledge later on. Complex Assignments ------------------- Complex assignments are defined as those with multiple targets to assign from a single source and are re-formulated to such using a temporary variable and multiple simple assignments instead. .. code:: python a = b = c .. code:: python _tmp = c a = _tmp b = _tmp del _tmp This is possible, because in Python, if one assignment fails, it can just be interrupted, so in fact, they are sequential, and all that is required is to not calculate ``c`` twice, which the temporary variable takes care of. Were ``b`` a more complex expression, e.g. ``b.some_attribute`` that might raise an exception, ``a`` would still be assigned. Unpacking Assignments --------------------- Unpacking assignments are re-formulated to use temporary variables as well. .. code:: python a, b.attr, c[ind] = d = e, f, g = h() Becomes this: .. code:: python _tmp = h() _iter1 = iter(_tmp) _tmp1 = unpack(_iter1, 3) _tmp2 = unpack(_iter1, 3) _tmp3 = unpack(_iter1, 3) unpack_check(_iter1) a = _tmp1 b.attr = _tmp2 c[ind] = _tmp3 d = _tmp _iter2 = iter(_tmp) _tmp4 = unpack(_iter2, 3) _tmp5 = unpack(_iter2, 3) _tmp6 = unpack(_iter2, 3) unpack_check(_iter1) e = _tmp4 f = _tmp5 g = _tmp6 That way, the unpacking is decomposed into multiple simple statements. It will be the job of optimizations to try and remove unnecessary unpacking, in case e.g. the source is a known tuple or list creation. .. note:: The ``unpack`` is a special node which is a form of ``next`` that will raise a ``ValueError`` when it cannot get the next value, rather than a ``StopIteration``. The message text contains the number of values to unpack, therefore the integer argument. .. note:: The ``unpack_check`` is a special node that raises a ``ValueError`` exception if the iterator is not finished, i.e. there are more values to unpack. Again the number of values to unpack is provided to construct the error message. With Statements --------------- The ``with`` statements are re-formulated to use temporary variables as well. The taking and calling of ``__enter__`` and ``__exit__`` with arguments, is presented with standard operations instead. The promise to call ``__exit__`` is fulfilled by ``try``/``except`` clause instead. .. code:: python with some_context as x: something(x) .. code:: python tmp_source = some_context # Actually it needs to be "special look-up" for Python2.7, so attribute # look-up won't be exactly what is there. tmp_exit = tmp_source.__exit__ # This one must be held for the whole with statement, it may be assigned # or not, in our example it is. If an exception occurs when calling # ``__enter__``, the ``__exit__`` should not be called. tmp_enter_result = tmp_source.__enter__() # Indicator variable to know if "tmp_exit" has been called. tmp_indicator = False try: # Now the assignment is to be done, if there is any name for the # manager given, this may become multiple assignment statements and # even unpacking ones. x = tmp_enter_result # Then the code of the "with" block. something(x) except Exception: # Note: This part of the code must not set line numbers, which we # indicate with special source code references, which we call "internal". # Otherwise the line of the frame would get corrupted. tmp_indicator = True if not tmp_exit(*sys.exc_info()): raise finally: if not tmp_indicator: # Call the exit if no exception occurred with all arguments # as "None". tmp_exit(None, None, None) .. note:: We don't refer really to ``sys.exc_info()`` at all, instead, we have fast references to the current exception type, value and trace, taken directly from the caught exception object on the C level. If we had the ability to optimize ``sys.exc_info()`` to do that, we could use the same transformation, but right now we don't have it. For Loops --------- The ``for`` loops use normal assignments and handle the iterator that is implicit in the code explicitly. .. code:: python for x, y in iterable: if something(x): break else: otherwise() This is roughly equivalent to the following code: .. code:: python _iter = iter(iterable) _no_break_indicator = False while 1: try: _tmp_value = next(_iter) except StopIteration: # Set the indicator that the else branch may be executed. _no_break_indicator = True # Optimization should be able to tell that the else branch is run # only once. break # Normal assignment re-formulation applies to this assignment of course. x, y = _tmp_value del _tmp_value if something(x): break if _no_break_indicator: otherwise() .. note:: The ``_iter`` temporary variable is of course also in a ``try/finally`` construct, to make sure it releases after its used. The ``x, y`` assignment is of course subject to unpacking re-formulation. The ``try``/``except`` is detected to allow to use a variant of ``next`` that does not raise an exception, but to be fast check about the ``NULL`` return from ``next`` built-in. So no actual exception handling is happening in this case. While Loops ----------- Quoting the ``nuitka.tree.ReformulationWhileLoopStatements`` documentation: Reformulation of while loop statements. Loops in Nuitka have no condition attached anymore, so while loops are re-formulated like this: .. code:: python while condition: something() .. code:: python while 1: if not condition: break something() This is to totally remove the specialization of loops, with the condition moved to the loop body in an initial conditional statement, which contains a ``break`` statement. That achieves, that only ``break`` statements exit the loop, and allow for optimization to remove always true loop conditions, without concerning code generation about it, and to detect such a situation, consider e.g. endless loops. .. note:: Loop analysis (not yet done) can then work on a reduced problem (which ``break`` statements are executed under what conditions) and is then automatically very general. The fact that the loop body may not be entered at all, is still optimized, but also in the general sense. Explicit breaks at the loop start and loop conditions are the same. End quoting the ``nuitka.tree.ReformulationWhileLoopStatements`` documentation: Exception Handlers ------------------ Exception handlers in Python may assign the caught exception value to a variable in the handler definition. And the different handlers are represented as conditional checks on the result of comparison operations. .. code:: python try: block() except A as e: handlerA(e) except B as e: handlerB(e) else: handlerElse() .. code:: python try: block() except: # These are special nodes that access the exception, and don't really # use the "sys" module. tmp_exc_type = sys.exc_info()[0] tmp_exc_value = sys.exc_info()[1] # exception_matches is a comparison operation, also a special node. if exception_matches(tmp_exc_type, (A,)): e = tmp_exc_value handlerA(e) elif exception_matches(tmp_exc_type, (B,)): e = tmp_exc_value handlerB(e) else: handlerElse() For Python3, the assigned ``e`` variables get deleted at the end of the handler block. Should that value be already deleted, that ``del`` does not raise, therefore it's tolerant. This has to be done in any case, so for Python3 it is even more complex. .. code:: python try: block() except: # These are special nodes that access the exception, and don't really # use the "sys" module. tmp_exc_type = sys.exc_info()[0] tmp_exc_value = sys.exc_info()[1] # exception_matches is a comparison operation, also a special node. if exception_matches(tmp_exc_type, (A,)): try: e = tmp_exc_value handlerA(e) finally: del e elif exception_matches(tmp_exc_type, (B,)): try: e = tmp_exc_value handlerB(e) finally: del e else: handlerElse() Should there be no ``else:`` branch, a default re-raise statement is used instead. And of course, the values of the current exception type and value, both use special references, that access the C++ and don't go via ``sys.exc_info`` at all, nodes called ``CaughtExceptionTypeRef`` and ``CaughtExceptionValueRef``. This means, that the different handlers and their catching run time behavior are all explicit and reduced the branches. Statement ``try``/``except`` with ``else`` ------------------------------------------ Much like ``else`` branches of loops, an indicator variable is used to indicate the entry into any of the exception handlers. Therefore, the ``else`` becomes a real conditional statement in the node tree, checking the indicator variable and guarding the execution of the ``else`` branch. Class Creation (Python2) ------------------------ Classes in Python2 have a body that only serves to build the class dictionary and is a normal function otherwise. This is expressed with the following re-formulation: .. code:: python # in module "SomeModule" # ... class SomeClass(SomeBase, AnotherBase): """ This is the class documentation. """ some_member = 3 .. code:: python def _makeSomeClass(): # The module name becomes a normal local variable too. __module__ = "SomeModule" # The doc string becomes a normal local variable. __doc__ = """ This is the class documentation. """ some_member = 3 return locals() # force locals to be a writable dictionary, will be optimized away, but # that property will stick. This is only to express, that locals(), where # used will be writable to. exec("") SomeClass = make_class("SomeClass", (SomeBase, AnotherBase), _makeSomeClass()) That is roughly the same, except that ``_makeSomeClass`` is *not* visible to its child functions when it comes to closure taking, which we cannot express in Python language at all. Therefore, class bodies are just special function bodies that create a dictionary for use in class creation. They don't really appear after the tree building stage anymore. The type inference will of course have to become able to understand ``make_class`` quite well, so it can recognize the created class again. Class Creation (Python3) ------------------------ In Python3, classes are a complicated way to write a function call, that can interact with its body. The body starts with a dictionary provided by the metaclass, so that is different, because it can ``__prepare__`` a non-empty locals for it, which is hidden away in "prepare_class_dict" below. What's noteworthy, is that this dictionary, could e.g. be an ``OrderDict``. I am not sure, what ``__prepare__`` is allowed to return. .. code:: python3 # in module "SomeModule" # ... class SomeClass(SomeBase, AnotherBase, metaclass = SomeMetaClass): """ This is the class documentation. """ some_member = 3 .. code:: python # Non-keyword arguments, need to be evaluated first. tmp_bases = (SomeBase, AnotherBase) # Keyword arguments go next, __metaclass__ is just one of them. In principle # we need to forward the others as well, but this is ignored for the sake of # brevity. tmp_metaclass = select_metaclass(tmp_bases, SomeMetaClass) tmp_prepared = tmp_metaclass.__prepare__("SomeClass", tmp_bases) # The function that creates the class dictionary. Receives temporary variables # to work with. def _makeSomeClass(): # This has effect, currently I don't know how to express that in Python3 # syntax, but we will have a node that does that. locals().replace(tmp_prepared) # The module name becomes a normal local variable too. __module__ = "SomeModule" # The doc string becomes a normal local variable. __doc__ = """ This is the class documentation. """ some_member = 3 # Create the class, share the potential closure variable "__class__" # with others. __class__ = tmp_metaclass("SomeClass", tmp_bases, locals()) return __class__ # Build and assign the class. SomeClass = _makeSomeClass() Generator Expressions --------------------- There are re-formulated as functions. Generally they are turned into calls of function bodies with (potentially nested) for loops: .. code:: python gen = (x * 2 for x in range(8) if cond()) .. code:: python def _gen_helper(__iterator): for x in __iterator: if cond(): yield x * 2 gen = _gen_helper(range(8)) List Contractions ----------------- The list contractions of Python2 are different from those of Python3, in that they don't actually do any closure variable taking, and that no function object ever exists. .. code:: python list_value = [x * 2 for x in range(8) if cond()] .. code:: python def _listcontr_helper(__iterator): result = [] for x in __iterator: if cond(): result.append(x * 2) return result list_value = _listcontr_helper(range(8)) The difference is that with Python3, the function "_listcontr_helper" is really there and named ```` (or ```` as of Python3.7 or higher), whereas with Python2 the function is only an outline, so it can readily access the containing name space. Set Contractions ---------------- The set contractions of Python2.7 are like list contractions in Python3, in that they produce an actual helper function: .. code:: python set_value = {x * 2 for x in range(8) if cond()} .. code:: python def _setcontr_helper(__iterator): result = set() for x in __iterator: if cond(): result.add(x * 2) return result set_value = _setcontr_helper(range(8)) Dictionary Contractions ----------------------- The dictionary contractions of are like list contractions in Python3, in that they produce an actual helper function: .. code:: python dict_value = {x: x * 2 for x in range(8) if cond()} .. code:: python def _dictcontr_helper(__iterator): result = {} for x in __iterator: if cond(): result[x] = x * 2 return result set_value = _dictcontr_helper(range(8)) Boolean expressions ``and`` and ``or`` -------------------------------------- The short circuit operators ``or`` and ``and`` tend to be only less general that the ``if``/``else`` expressions, but have dedicated nodes. We used to have a re-formulation towards those, but we now do these via dedicated nodes too. These new nodes, present the evaluation of the left value, checking for its truth value, and depending on it, to pick it, or use the right value. Simple Calls ------------ As seen below, even complex calls are simple calls. In simple calls of Python there is still some hidden semantic going on, that we expose. .. code:: python func(arg1, arg2, named1=arg3, named2=arg4) On the C-API level there is a tuple and dictionary built. This one is exposed: .. code:: python func(*(arg1, arg2), **{"named1": arg3, "named2": arg4}) A called function will access this tuple and the dictionary to parse the arguments, once that is also re-formulated (argument parsing), it can then lead to simple in-lining. This way calls only have 2 arguments with constant semantics, that fits perfectly with the C-API where it is the same, so it is actually easier for code generation. Although the above looks like a complex call, it actually is not. No checks are needed for the types of the star arguments and it's directly translated to ``PyObject_Call``. Complex Calls ------------- The call operator in Python allows to provide arguments in 4 forms. - Positional (or normal) arguments - Named (or keyword) arguments - Star list arguments - Star dictionary arguments The evaluation order is precisely that. An example would be: .. code:: python something(pos1, pos2, name1=named1, name2=named2, *star_list, **star_dict) The task here is that first all the arguments are evaluated, left to right, and then they are merged into only two, that is positional and named arguments only. for this, the star list argument and the star dictionary arguments, are merged with the positional and named arguments. What's peculiar, is that if both the star list and dictionary arguments are present, the merging is first done for star dictionary, and only after that for the star list argument. This makes a difference, because in case of an error, the star argument raises first. .. code:: python something(*1, **2) This raises "TypeError: something() argument after ** must be a mapping, not int" as opposed to a possibly more expected "TypeError: something() argument after * must be a sequence, not int." That doesn't matter much though, because the value is to be evaluated first anyway, and the check is only performed afterwards. If the star list argument calculation gives an error, this one is raised before checking the star dictionary argument. So, what we do, is we convert complex calls by the way of special functions, which handle the dirty work for us. The optimization is then tasked to do the difficult stuff. Our example becomes this: .. code:: python def _complex_call(called, pos, kw, star_list_arg, star_dict_arg): # Raises errors in case of duplicate arguments or tmp_star_dict not # being a mapping. tmp_merged_dict = merge_star_dict_arguments( called, tmp_named, mapping_check(called, tmp_star_dict) ) # Raises an error if tmp_star_list is not a sequence. tmp_pos_merged = merge_pos_arguments(called, tmp_pos, tmp_star_list) # On the C-API level, this is what it looks like. return called(*tmp_pos_merged, **tmp_merged_dict) returned = _complex_call( called=something, pos=(pos1, pos2), named={"name1": named1, "name2": named2}, star_list_arg=star_list, star_dict_arg=star_dict, ) The call to ``_complex_call`` is be a direct function call with no parameter parsing overhead. And the call in its end, is a special call operation, which relates to the ``PyObject_Call`` C-API. Assignment Expressions ---------------------- In Python 3.8 or higher, you assign inside expressions. .. code:: python if (x := cond()): do_something() this is the same as: .. code:: python # Doesn't exist with that name, and it is not really taking closure variables, # it just shares the execution context. def _outline_func(): nonlocal x x = cond() return x if (_outline_func()): do_something When we use this outline function, we are allowed statements, even assignments, in expressions. For optimization, they of course pose a challenge to be removed ever, only happens when it becomes only a return statement, but they do not cause much difficulties for code generation, since they are transparent. Match Statements ---------------- In Python 3.10 or higher, you can write so called ``match`` statements like this: .. code:: python match something(): case [x] if x: z = 2 case _ as y if y == x and y: z = 1 case 0: z = 0 This is the same as .. code:: python tmp_match_subject = something() # Indicator variable, once true, all matching stops. tmp_handled = False # First branch x = tmp_match_subject if sequence_check(x) if x: z = 2 tmp_handled = True if tmp_handled is False: y = tmp_match_subject if x == y and y: z = 1 tmp_handled = True if tmp_handled is False: z = 0 Print Statements ---------------- The ``print`` statement exists only in Python2. It implicitly converts its arguments to strings before printing them. In order to make this accessible and compile time optimized, this is made visible in the node tree. .. code:: python print arg1, "1", 1 This is in Nuitka converted so that the code generation for ``print`` doesn't do any conversions itself anymore and relies on the string nature of its input. .. code:: python print str(arg1), "1", str(1) Only string objects are spared from the ``str`` built-in wrapper, because that would only cause noise in optimization stage. Later optimization can then find it unnecessary for certain arguments. Additionally, each ``print`` may have a target, and multiple arguments, which we break down as well for dumber code generation. The target is evaluated first and should be a file, kept referenced throughout the whole print statement. .. code:: python print >> target_file, str(arg1), "1", str(1) This is being reformulated to: .. code:: python try: tmp_target = target_file print >>tmp_target, str(arg1), print >>tmp_target, "1", print >>tmp_target, str(1), print >>tmp_target finally: del tmp_target This allows code generation to not deal with arbitrary amount of arguments to ``print``. It also separates the newline indicator from the rest of things, which makes sense too, having it as a special node, as it's behavior with regards to soft-space is different of course. And finally, for ``print`` without a target, we still assume that a target was given, which would be ``sys.stdout`` in a rather hard-coded way (no variable look-ups involved). Reformulations during Optimization ================================== Builtin ``zip`` for Python2 --------------------------- .. code:: python def _zip(a, b, c): # Potentially more arguments. # First assign, to preserve the order of execution, the arguments might be # complex expressions with side effects. tmp_arg1 = a tmp_arg2 = b tmp_arg3 = c # could be more ... # Creation of iterators goes first. try: tmp_iter_1 = iter(tmp_arg1) except TypeError: raise TypeError("zip argument #1 must support iteration") try: tmp_iter_2 = iter(tmp_arg2) except TypeError: raise TypeError("zip argument #2 must support iteration") try: tmp_iter_3 = iter(tmp_arg3) except TypeError: raise TypeError("zip argument #3 must support iteration") # could be more ... tmp_result = [] try: while 1: tmp_result.append( ( next(tmp_iter_1), next(tmp_iter_2), next(tmp_iter_3), # more arguments here ... ) ) except StopIteration: pass return tmp_result Builtin ``zip`` for Python3 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code:: python for x, y, z in zip(a, b, c): ... .. code:: python def _zip_gen_object(a, b, c, ...): ... # See Python2 ... # could be more ... while 1: yield ( next(tmp_iter_1), next(tmp_iter_2), next(tmp_iter_3), ... ) except StopIteration: break for x, y, z in _zip_gen_object(a, b, c): ... Builtin ``map`` for Python2 --------------------------- .. code:: python def _map(): # TODO: Not done yet. pass Builtin ``min`` --------------- .. code:: python # TODO: keyfunc (Python2/3), defaults (Python3) def _min(a, b, c): # Potentially more arguments. tmp_arg1 = a tmp_arg2 = b tmp_arg3 = c # more arguments here ... result = tmp_arg1 if keyfunc is None: # can be decided during re-formulation tmp_key_result = keyfunc(result) tmp_key_candidate = keyfunc(tmp_arg2) if tmp_key_candidate < tmp_key_result: result = tmp_arg2 tmp_key_result = tmp_key_candidate tmp_key_candidate = keyfunc(tmp_arg3) if tmp_key_candidate < tmp_key_result: result = tmp_arg3 tmp_key_result = tmp_key_candidate # more arguments here ... else: if tmp_arg2 < result: result = tmp_arg2 if tmp_arg3 < result: result = tmp_arg3 # more arguments here ... return result Builtin ``max`` --------------- See ``min`` just with ``>`` instead of ``<``. Call to ``dir`` without arguments --------------------------------- This expression is reformulated to ``locals().keys()`` for Python2, and ``list(locals.keys())`` for Python3. Calls to functions with known signatures ---------------------------------------- As a necessary step for inlining function calls, we need to change calls to variable references to function references. .. code:: python def f(arg1, arg2): return some_op(arg1, arg2) # ... other code x = f(a, b + c) In the optimization it is turned into .. code:: python # ... other code x = lambda arg1, arg2: some_op(arg1, arg2)(a, b + c) .. note:: The ``lambda`` stands here for a reference to the function, rather than a variable reference, this is the normal forward propagation of values, and does not imply duplicating or moving any code at all. At this point, we still have not resolved the actual call arguments to the variable names, still a Python level function is created, and called, and arguments are parsed to a tuple, and from a tuple. For simplicity sake, we have left out keyword arguments out of the equation for now, but they are even more costly. So now, what we want to do, is to re-formulate the call into what we call an outline body, which is a inline function, and that does the parameter parsing already and contains the function code too. In this inlining, there still is a function, but it's technically not a Python function anymore, just something that is an expression whose value is determined by control flow and the function call. .. code:: python # ... other code def _f(): tmp_arg1 = arg1 tmp_arg2 = b + c return tmp_arg1 + tmp_arg2 x = _f() With this, a function is considered inlined, because it becomes part of the abstract execution, and the actual code is duplicated. The point is, that matching the signature of the function to the actual arguments given, is pretty straight forward in many cases, but there are two forms of complications that can happen. One is default values, because they need to assigned or not, and the other is keyword arguments, because they allow to reorder arguments. Let's consider an example with default values first. .. code:: python def f(arg1, arg2=some_default()): return some_op(arg1, arg2) # ... other code x = f(a, b + c) Since the point, at which defaults are taken, we must execute them at that point and make them available. .. code:: python tmp_defaults = (some_default,) # that was f.__defaults__ # ... other code def _f(): tmp_arg1 = arg1 tmp_arg2 = tmp_defaults[0] return tmp_arg1 + tmp_arg2 x = _f() Now, one where keyword arguments are ordered the other way. .. code:: python def f(arg1, arg2): return some_op(arg1, arg2) # ... other code x = f(arg2=b + c, arg1=a) # "b+c" is evaluated before "a" The solution is an extra level of temporary variables. We remember the argument order by names and then assign parameters from it: .. code:: python # ... other code def _f(): tmp_given_value1 = b + c tmp_given_value2 = a tmp_arg1 = tmp_given_value2 tmp_arg2 = tmp_given_value1 return tmp_arg1 + tmp_arg2 x = _f() Obviously, optimization of Nuitka can decide, that e.g. should ``a`` or ``b+c`` not have side effects, to optimize these with standard variable tracing away. Nodes that serve special purposes ================================= Try statements -------------- In Python, there is ``try``/``except`` and ``try``/``finally``. In Nuitka there is only a ``try``, which then has blocks to handle exceptions, ``continue``, or ``break``, or ``return``. There is no ``else`` to this node type. This is more low level and universal. Code for the different handlers can be different. User provided ``finally`` blocks become copied into the different handlers. Releases -------- When a function exits, the local variables are to be released. The same applies to temporary variables used in re-formulations. These releases cause a reference to the object to the released, but no value change. They are typically the last use of the object in the function. The are similar to ``del``, but make no value change. For shared variables this effect is most visible. Side Effects ------------ When an exception is bound to occur, and this can be determined at compile time, Nuitka will not generate the code the leads to the exception, but directly just raise it. But not in all cases, this is the full thing. Consider this code: .. code:: python f(a(), 1 / 0) The second argument will create a ``ZeroDivisionError`` exception, but before that ``a()`` must be executed, but the call to ``f`` will never happen and no code is needed for that, but the name look-up must still succeed. This then leads to code that is internally like this: .. code:: python f(a(), raise_ZeroDivisionError()) which is then modeled as: .. code:: python side_effect(a(), f, raise_ZeroDivisionError()) where we can consider ``side_effect`` to be a function that returns the last expression. Of course, if this is not part of another expression, but close to statement level, side effects, can be converted to multiple statements simply. Another use case, is that the value of an expression can be predicted, but that the language still requires things to happen, consider this: .. code:: python a = len((f(), g())) We can tell that ``a`` will be 2, but the call to ``f`` and ``g`` must still be performed, so it becomes: .. code:: python a = side_effects(f(), g(), 2) Modelling side effects explicitly has the advantage of recognizing them easily and allowing to drop the call to the tuple building and checking its length, only to release it. Caught Exception Type/Value References -------------------------------------- When catching an exception, these are not directly put to ``sys.exc_info()``, but remain as mere C variables. From there, they can be accessed with these nodes, or if published then from the thread state. Hard Module Imports ------------------- These are module look-ups that don't depend on any local variable for the module to be looked up, but with hard-coded names. These may be the result of optimization gaining such level of certainty. Currently they are used to represent ``sys.stdout`` usage for ``print`` statements, but other usages will follow. Locals Dict Update Statement ---------------------------- For the ``exec`` re-formulation, we apply an explicit sync back to locals as an explicit node. It helps us to tell the affected local variable traces that they might be affected. It represents the bit of ``exec`` in Python2, that treats ``None`` as the locals argument as an indication to copy back. Optimizing Attribute Lookups into Method Calls for Built-ins types ================================================================== The attribute lookup node ``ExpressionAttributeLookup`` represents looking up an attribute name, that is known to be a string. That's already a bit more special, than say what ``ExpressionBuiltinGetattr`` does for ``getattr``, where it could be any object being looked up. From the Python syntax however, these are what gets created, as it's not allowed in any other way. So, this is where this starts. Then, when we are creating an attribute node with a *fixed* name, we dispatch it to generated node classes, e.g. ``ExpressionAttributeLookupFixedAppend``. This will be the same, except that the attribute name is hardcoded. There are generated, such that they can have code that is special for ``.append`` lookups. In their case, it makes sense to ask the source, if they are a ``list`` object exactly. It doesn't make sense to do this check for names that the ``list`` does not contain. So at that stage, we are saving both a bit of memory and time. Should this question succeed, i.e. the expression the attribute values is looked up upon, is known to be a ``list`` exactly, we persist this knowledge in the also generated nodes that represent ``list.append`` and just that. It is called ``ExpressionAttributeLookupListAppend`` and only represents the knowledge gained so far. We do not consider if ``ExpressionAttributeLookupFixedAppend`` is called, or not, passed as an argument, assigned somewhere, it doesn't matter yet, but for ``ExpressionAttributeLookupListAppend`` we know a hell of a lot more. We know its type, we know attributes for it, say ``__name__``, as it is a compile time constant, therefore much optimization can follow for them, and code generation can specialize them too (not yet done). Should these nodes then, and say this happens later after some inlining happens be seen as called, we can then turn them into method call nodes, checking the arguments and such, this is then ``ExpressionListOperationAppend`` and at this point, will raising errors with wrong argument counts. And then we have this ``ExpressionListOperationAppend`` which will influence the tracing of ``list`` contents, i.e. it will be able to tell the ``list`` in question is no more empty after this ``append``, and it will be able to at least predict the last element value, truth value of the list, etc. ****************************** Plan to add "ctypes" support ****************************** Add interfacing to C code, so Nuitka can turn a ``ctypes`` binding into an efficient binding as if it were written manually with Python C-API or better. Goals/Allowances to the task ============================ #. Goal: Must not directly use any pre-existing C/C++ language file headers, only generate declarations in generated C code ourselves. We would rather write or use tools that turn an existing a C header to some ``ctypes`` declarations if it needs to be, but not mix and use declarations from existing header code. .. note:: The "cffi" interface maybe won't have the issue, but it's not something we need to write or test the code for. #. Allowance: May use ``ctypes`` module at compile time to ask things about ``ctypes`` and its types. #. Goal: Should make use of ``ctypes``, to e.g. not hard code in Nuitka what ``ctypes.c_int()`` gives on the current platform, unless there is a specific benefit. #. Allowance: Not all ``ctypes`` usages must be supported immediately. #. Goal: Try and be as general as possible. For the compiler, ``ctypes`` support should be hidden behind a generic interface of some sort. Supporting ``math`` module should be the same thing. Type Inference - The Discussion =============================== Main initial goal is to forward value knowledge. When you have ``a = b``, that means that a and b now "alias". And if you know the value of ``b`` you can assume to know the value of ``a``. This is called "aliasing". When assigning ``a`` to something new, that won't change ``b`` at all. But when an attribute is set, a method called of it, that might impact the actual value, referenced by both. We need to understand mutable vs. immutable though, as some things are not affected by aliasing in any way. .. code:: python a = 3 b = a b += 4 # a is not changed a = [3] b = a b += [4] # a is changed indeed If we cannot tell, we must assume that ``a`` might be changed. It's either ``b`` or what ``a`` was before. If the type is not mutable, we can assume the aliasing to be broken up, and if it is, we can assume both to be the same value still. When that value is a compile time constant, we will want to push it forward, and we do that with "(Constant) Value Propagation", which is implemented already. We avoid too large constants, and we properly trace value assignments, but not yet aliases. In order to fully benefit from type knowledge, the new type system must be able to be fully friends with existing built-in types, but for classes to also work with it, it should not be tied to them. The behavior of a type ``long``, ``str``, etc. ought to be implemented as far as possible with the built-in ``long``, ``str`` at compiled time as well. .. note:: This "use the real thing" concept extends beyond builtin types, e.g. ``ctypes.c_int()`` should also be used, but we must be aware of platform dependencies. The maximum size of ``ctypes.c_int`` values would be an example of that. Of course that may not be possible for everything. This approach has well proven itself with built-in functions already, where we use real built-ins where possible to make computations. We have the problem though that built-ins may have problems to execute everything with reasonable compile time cost. Another example, consider the following code: .. code:: python len("a" * 1000000000000) To predict this code, calculating it at compile time using constant operations, while feasible, puts an unacceptable burden on the compilation. Esp. we wouldn't want to produce such a huge constant and stream it, the C++ code would become too huge. So, we need to stop the ``*`` operator from being used at compile time and cope with reduced knowledge, already here: .. code:: python "a" * 10000000000000 Instead, we would probably say that for this expression: - The result is a ``str`` or a C level ``PyStringObject *``. - We know its length exactly, it's ``10000000000000``. - Can predict every of its elements when sub-scripted, sliced, etc., if need be, with a function we may create. Similar is true for this horrible (in Python2) thing: .. code:: python range(10000000000000) So it's a rather general problem, this time we know: - The result is a ``list`` or C level ``PyListObject *``. - We know its length exactly, ``10000000000000``. - Can predict every of its elements when index, sliced, etc., if need be, with a function. Again, we wouldn't want to create the list. Therefore Nuitka avoids executing these calculation, when they result in constants larger than a threshold of e.g. 256 elements. This concept has to be also applied to large integers and more CPU and memory traps. Now lets look at a more complete use case: .. code:: python for x in range(10000000000000): doSomething() Looking at this example, one traditional way to look at it, would be to turn ``range`` into ``xrange``, and to note that ``x`` is unused. That would already perform better. But really better is to notice that ``range()`` generated values are not used at all, but only the length of the expression matters. And even if ``x`` were used, only the ability to predict the value from a function would be interesting, so we would use that computation function instead of having an iteration source. Being able to predict from a function could mean to have Python code to do it, as well as C code to do it. Then code for the loop can be generated without any CPython library usage at all. .. note:: Of course, it would only make sense where such calculations are "O(1)" complexity, i.e. do not require recursion like "n!" does. The other thing is that CPython appears to at - run time - take length hints from objects for some operations, and there it would help too, to track length of objects, and provide it, to outside code. Back to the original example: .. code:: python len("a" * 1000000000000) The theme here, is that when we can't compute all intermediate expressions, and we sure can't do it in the general case. But we can still, predict some of properties of an expression result, more or less. Here we have ``len`` to look at an argument that we know the size of. Great. We need to ask if there are any side effects, and if there are, we need to maintain them of course. This is already done by existing optimization if an operation generates an exception. .. note:: The optimization of ``len`` has been implemented and works for all kinds of container creation and ranges. Applying this to "ctypes" ========================= The *not so specific* problem to be solved to understand ``ctypes`` declarations is maybe as follows: .. code:: python import ctypes This leads to Nuitka in its tree to have an assignment from a ``__import__`` expression to the variable ``ctypes``. It can be predicted by default to be a module object, and even better, it can be known as ``ctypes`` from standard library with more or less certainty. See the section about "Importing". So that part is "easy", and it's what will happen. During optimization, when the module ``__import__`` expression is examined, it should say: - ``ctypes`` is a module - ``ctypes`` is from standard library (if it is, might not be true) - ``ctypes`` then has code behind it, called ``ModuleFriend`` that knows things about it attributes, that should be asked. The later is the generic interface, and the optimization should connect the two, of course via package and module full names. It will need a ``ModuleFriendRegistry``, from which it can be pulled. It would be nice if we can avoid ``ctypes`` to be loaded into Nuitka unless necessary, so these need to be more like a plug-in, loaded only if necessary, i.e. the user code actually uses ``ctypes``. Coming back to the original expression, it also contains an assignment expression, because it re-formulated to be more like this: .. code:: python ctypes = __import__("ctypes") The assigned to object, simply gets the type inferred propagated as part of an SSA form. Ideally, we could be sure that nothing in the program changes the variable, and therefore have only one version of that variable. For module variables, when the execution leaves the module to unknown code, or unclear code, it might change the variable. Therefore, likely we will often only assume that it could still be ``ctypes``, but also something else. Depending on how well we control module variable assignment, we can decide this more of less quickly. With "compiled modules" types, the expectation is that it's merely a quick C ``==`` comparison check. The module friend should offer code to allow a check if it applies, for uncertain cases. Then when we come to uses of it: .. code:: python ctypes.c_int() At this point, using SSA, we are more of less sure, that ``ctypes`` is at that point the module, and that we know what it's ``c_int`` attribute is, at compile time, and what it's call result is. We will use the module friend to help with that. It will attach knowledge about the result of that expression during the SSA collection process. This is more like a value forward propagation than anything else. In fact, constant propagation should only be the special case of it, and one design goal of Nuitka was always to cover these two cases with the same code. Excursion to Functions ====================== In order to decide what this means to functions and their call boundaries, if we propagate forward, how to handle this: .. code:: python def my_append(a, b): a.append(b) return a We annotate that ``a`` is first a "unknown but defined parameter object", then later on something that definitely has an ``append`` attribute, when returned, as otherwise an exception occurs. The type of ``a`` changes to that after ``a.append`` look-up succeeds. It might be many kinds of an object, but e.g. it could have a higher probability of being a ``PyListObject``. And we would know it cannot be a ``PyStringObject``, as that one has no ``append`` method, and would have raised an exception therefore. .. note:: If classes, i.e. other types in the program, have an ``append`` attribute, it should play a role too, there needs to be a way to plug-in to this decisions. .. note:: On the other hand, types without ``append`` attribute can be eliminated. Therefore, functions through SSA provide an automatic analysis on their return state, or return value types, or a quick way to predict return value properties, based on input value knowledge. So this could work: .. code:: python b = my_append([], 3) assert b == [3] # Could be decided now Goal: The structure we use makes it easy to tell what ``my_append`` may be. So, there should be a means to ask it about call results with given type/value information. We need to be able to tell, if evaluating ``my_append`` makes sense with given parameters or not, if it does impact the return value. We should e.g. be able to make ``my_append`` tell, one or more of these: - Returns the first parameter value as return value (unless it raises an exception). - The return value has the same type as ``a`` (unless it raises an exception). - The return value has an ``append`` attribute. - The return value might be a ``list`` object. - The return value may not be a ``str`` object. - The function will raise if first argument has no ``append`` attribute. The exactness of statements may vary. But some things may be more interesting. If e.g. the aliasing of a parameter value to the return value is known exactly, then information about it need to all be given up, but some can survive. It would be nice, if ``my_append`` had sufficient information, so we could specialize with ``list`` and ``int`` from the parameters, and then e.g. know at least some things that it does in that case. Such specialization would have to be decided if it makes sense. In the alternative, it could be done for each variant anyway, as there won't be that many of them. Doing this "forward" analysis appears to be best suited for functions and therefore long term. We will try it that way. Excursion to Loops ================== .. code:: python a = 1 while 1: # think loop: here b = a + 1 a = b if cond(): break print(a) The handling of loops (both ``for`` and ``while`` are re-formulated to this kind of loops with ``break`` statements) has its own problem. The loop start and may have an assumption from before it started, that ``a`` is constant, but that is only true for the first iteration. So, we can't pass knowledge from outside loop forward directly into the for loop body. So the collection for loops needs to be two pass for loops. First, to collect assignments, and merge these into the start state, before entering the loop body. The need to make two passes is special to loops. For a start, it is done like this. At loop entry, all pre-existing, but written traces, are turned into loop merges. Knowledge is not completely removed about everything assigned or changed in the loop, but then it's not trusted anymore. From that basis, the ``break`` exits are analysed, and merged, building up the post loop state, and ``continue`` exits of the loop replacing the unknown part of the loop entry state. The loop end is considered a ``continue`` for this purpose. Excursion to Conditions ======================= .. code:: python if cond: x = 1 else: x = 2 b = x < 3 The above code contains a condition, and these have the problem, that when exiting the conditional block, a merge must be done, of the ``x`` versions. It could be either one. The merge may trace the condition under which a choice is taken. That way, we could decide pairs of traces under the same condition. These merges of SSA variable "versions", represent alternative values. They pose difficulties, and might have to be reduced to commonality. In the above example, the ``<`` operator will have to check for each version, and then to decide that both indeed give the same result. The trace collection tracks variable changes in conditional branches, and then merges the existing state at conditional statement exits. .. note:: A branch is considered "exiting" if it is not abortive. Should it end in a ``raise``, ``break``, ``continue``, or ``return``, there is no need to merge that branch, as execution of that branch is terminated. Should both branches be abortive, that makes things really simple, as there is no need to even continue. Should only one branch exist, but be abortive, then no merge is needed, and the collection can assume after the conditional statement, that the branch was not taken, and continue. When exiting both the branches, these branches must both be merged, with their new information. In the above case: - The "yes" branch knows variable ``x`` is an ``int`` of constant value ``1`` - The "no" branch knows variable ``x`` is an ``int`` of constant value ``2`` That might be collapsed to: - The variable ``x`` is an integer of value in ``(1,2)`` Given this, we then should be able to pre-compute the value of this: .. code:: python b = x < 3 The comparison operator can therefore decide and tell: - The variable ``b`` is a boolean of constant value ``True``. Were it unable to decide, it would still be able to say: - The variable ``b`` is a boolean. For conditional statements optimization, it's also noteworthy, that the condition is known to pass or not pass the truth check, inside branches, and in the case of non-exiting single branches, after the statement it's not true. We may want to take advantage of it. Consider e.g. .. code:: python if type(a) is list: a.append(x) else: a += (x,) In this case, the knowledge that ``a`` is a list, could be used to generate better code and with the definite knowledge that ``a`` is of type list. With that knowledge the ``append`` attribute call will become the ``list`` built-in type operation. Excursion to ``return`` statements ================================== The ``return`` statement (like ``break``, ``continue``, ``raise``) is "aborting" to control flow. It is always the last statement of inspected block. When there statements to follow it, optimization will remove it as "dead code". If all branches of a conditional statement are "aborting", the statement is decided "aborting" too. If a loop doesn't abort with a break, it should be considered "aborting" too. Excursion to ``yield`` expressions ================================== The ``yield`` expression can be treated like a normal function call, and as such invalidates some known constraints just as much as they do. It executes outside code for an unknown amount of time, and then returns, with little about the outside world known anymore, if it's accessible from there. Mixed Types =========== Consider the following inside a function or module: .. code:: python if cond is not None: a = [x for x in something() if cond(x)] else: a = () A programmer will often not make a difference between ``list`` and ``tuple``. In fact, using a ``tuple`` is a good way to express that something won't be changed later, as these are mutable. .. note:: Better programming style, would be to use this: .. code:: python if cond is not None: a = tuple(x for x in something() if cond(x)) else: a = () People don't do it, because they dislike the performance hit encountered by the generator expression being used to initialize the tuple. But it would be more consistent, and so Nuitka is using it, and of course one day Nuitka ought to be able to make no difference in performance for it. To Nuitka though this means, that if ``cond`` is not predictable, after the conditional statement we may either have a ``tuple`` or a ``list`` type object in ``a``. In order to represent that without resorting to "I know nothing about it", we need a kind of ``min``/``max`` operating mechanism that is capable of say what is common with multiple alternative values. .. note:: At this time, we don't really have that mechanism to find the commonality between values. Back to "ctypes" ================ .. code:: python v = ctypes.c_int() Coming back to this example, we needed to propagate ``ctypes``, then we can propagate "something" from ``ctypes.int`` and then known what this gives with a call and no arguments, so the walk of the nodes, and diverse operations should be addressed by a module friend. In case a module friend doesn't know what to do, it needs to say so by default. This should be enforced by a base class and give a warning or note. Now to the interface ==================== The following is the intended interface: - Iteration with node methods ``computeStatement`` and ``computeExpression``. These traverse modules and functions (i.e. scopes) and visit everything in the order that Python executes it. The visiting object is ``TraceCollection`` and pass forward. Some node types, e.g. ``StatementConditional`` new create branch trace collections and handle the SSA merging at exit. - Replacing nodes during the visit. Both ``computeStatement`` and ``computeExpression`` are tasked to return potential replacements of themselves, together with "tags" (meaningless now), and a "message", used for verbose tracing. The replacement node of ``+`` operator, may e.g. be the pre-computed constant result, wrapped in side effects of the node, or the expression raised, again wrapped in side effects. - Assignments and references affect SSA. The SSA tree is initialized every time a scope is visited. Then during traversal, traces are built up. Every assignment and merge starts a new trace for that matter. References to a given variable version are traced that way. - Value escapes are traced too. When an operation hands over a value to outside code, it indicates so to the trace collection. This is for it to know, when e.g. a constant value, might be mutated meanwhile. - Nodes can be queried about their properties. There is a type shape and a value shape that each node can be asked about. The type shape offers methods that allow to check if certain operations are at all supported or not. These can always return ``True`` (yes), ``False`` (no), and ``None`` (cannot decide). In the case of the later, optimizations may not be able do much about it. Lets call these values "tri-state". There is also the value shape of a node. This can go deeper, and be more specific to a given node. The default implementation will be very pessimistic. Specific node types and shapes may then declare, that they e.g. have no side effects, will not raise for certain operations, have a known truth value, have a known iteration length, can predict their iteration values, etc. - Nodes are linked to certain states. During the collect, a variable reference, is linked to a certain trace state, and that can be used by parent operations. .. code:: python a = 1 b = a + a In this example, the references to ``a``, can look-up the ``1`` in the trace, and base value shape response to ``+`` on it. For compile time evaluation, it may also ask ``isCompileTimeConstant()`` and if both nodes will respond ``True``, then "getCompileTimeConstant()" will return ``1``, which will be be used in computation. Then ``extractSideEffects()`` for the ``a`` reference will return ``()`` and therefore, the result ``2`` will not be wrapped. An alternative approach would be ``hasTypeSlotAdd()`` on the both nodes, and they both do, to see if the selection mechanism used by CPython can be used to find which types ``+`` should be used. - Class for module import expression ``ExpressionImportModule``. This one just knows that something is imported, but not how or what it is assigned to. It will be able in a recursive compile, to provide the module as an assignment source, or the module variables or submodules as an attribute source when referenced from a variable trace or in an expression. - Base class for module friend ``ModuleFriendBase``. This is intended to provide something to overload, which e.g. can handle ``math`` in a better way. - Module ``ModuleFriendRegistry`` Provides a register function with ``name`` and instances of ``ValueFriendModuleBase`` to be registered. Recursed to modules should integrate with that too. The registry could well be done with a metaclass approach. - The module friends should each live in a module of their own. With a naming policy to be determined. These modules should add themselves via above mechanism to ``ModuleFriendRegistry`` and all shall be imported and register. Importing of e.g. ``ctypes`` should be delayed to when the friend is actually used. A meta class should aid this task. The delay will avoid unnecessary blot of the compiler at run time, if no such module is used. For "qt" and other complex stuff, this will be a must. - The walk should initially be single pass, and not maintain history. Instead optimization that needs to look at multiple things, e.g. "unused assignment", will look at the whole SSA collection afterwards. Discussing with examples ======================== The following examples: .. code:: python # Assignment, the source decides the type of the assigned expression a = b # Operator "attribute look-up", the looked up expression "ctypes" decides # via its trace. ctypes.c_int # Call operator, the called expressions decides with help of arguments, # which have been walked, before the call itself. called_expression_of_any_complexity() # import gives a module any case, and the "ModuleRegistry" may say more. import ctypes # From import need not give module, "x" decides what it is. from x import y # Operations are decided by arguments, and CPython operator rules between # argument states. a + b The optimization is mostly performed by walking of the tree and performing trace collection. When it encounters assignments and references to them, it considers current state of traces and uses it for ``computeExpression``. .. note:: Assignments to attributes, indexes, slices, etc. will also need to follow the flow of ``append``, so it cannot escape attention that a list may be modified. Usages of ``append`` that we cannot be sure about, must be traced to exist, and disallow the list to be considered known value again. Code Generation Impact ====================== Right now, code generation assumes that everything is a ``PyObject *``, i.e. a Python object, and does not take knowledge of ``int`` or other types into consideration at all, and it should remain like that for some time to come. Instead, ``ctypes`` value friend will be asked give ``Identifiers``, like other codes do too. And these need to be able to convert themselves to objects to work with the other things. But Code Generation should no longer require that operations must be performed on that level. Imagine e.g. the following calls: .. code:: python c_call(other_c_call()) Value returned by "other_c_call()" of say ``c_int`` type, should be possible to be fed directly into another call. That should be easy by having a ``asIntC()`` in the identifier classes, which the ``ctypes`` Identifiers handle without conversions. Code Generation should one day also become able to tell that all uses of a variable have only ``c_int`` value, and use ``int`` instead of ``PyObjectLocalVariable`` more or less directly. We could consider ``PyIntLocalVariable`` of similar complexity as ``int`` after the C++ compiler performed its in-lining. Such decisions would be prepared by finalization, which then would track the history of values throughout a function or part of it. Initial Implementation ====================== The basic interface will be added to *all* expressions and a node may override it, potentially using trace collection state, as attached during ``computeExpression``. Goal 1 (Reached) ---------------- Initially most things will only be able to give up on about anything. And it will be little more than a tool to do simple look-ups in a general form. It will then be the first goal to turn the following code into better performing one: .. code:: python a = 3 b = 7 c = a / b print(c) to: .. code:: python a = 3 b = 7 c = 3 / 7 print(c) and then: .. code:: python a = 3 b = 7 c = 0 print(c) and then: .. code:: python a = 3 b = 7 c = 0 print(0) This depends on SSA form to be able to tell us the values of ``a``, ``b``, and ``c`` to be written to by constants, which can be forward propagated at no cost. Goal 2 (Reached) ---------------- The assignments to ``a``, ``b``, and ``c`` shall all become prey to "unused" assignment analysis in the next step. They are all only assigned to, and the assignment source has no effect, so they can be simply dropped. .. code:: python print(0) In the SSA form, these are then assignments without references. These assignments, can be removed if the assignment source has no side effect. Or at least they could be made "anonymous", i.e. use a temporary variable instead of the named one. That would have to take into account though, that the old version still needs a release. The most general form would first merely remove assignments that have no impact, and leave the value as a side effect, so we arrive at this first: .. code:: python 3 7 0 print(0) When applying the removal of expression only statements without effect, this gives us: .. code:: python print(0) which is the perfect result. Doing it in one step would only be an optimization at the cost of generalization. In order to be able to manipulate nodes related to a variable trace, we need to attach the nodes that did it. Consider this: .. code:: python if cond(): x = 1 elif other(): x = 3 # Not using "x". print(0) In the above case, the merge of the value traces, should say that ``x`` may be undefined, or one of ``1`` or ``3``, but since ``x`` is not used, apply the "dead value" trick to each branch. The removal of the "merge" of the 3 ``x`` versions, should exhibit that the other versions are also only assigned to, and can be removed. These merges of course appear as usages of the ``x`` versions. Goal 3 ------ Then third goal is to understand all of this: .. code:: python def f(): a = [] print(a) for i in range(1000): print(a) a.append(i) return len(a) .. note:: There are many operations in this, and all of them should be properly handled, or at least ignored in safe way. The first goal code gave us that the ``list`` has an annotation from the assignment of ``[]`` and that it will be copied to ``a`` until the for loop in encountered. Then it must be removed, because the ``for`` loop somehow says so. The ``a`` may change its value, due to the unknown attribute look-up of it already, not even the call. The for loop must be able to say "may change value" due to that, of course also due to the call of that attribute too. The code should therefore become equivalent to: .. code:: python def f(): a = [] print([]) for i in range(1000): print(a) a.append(i) return len(a) But no other changes must occur, especially not to the ``return`` statement, it must not assume ``a`` to be constant "[]" but an unknown ``a`` instead. With that, we would handle this code correctly and have some form constant value propagation in place, handle loops at least correctly, and while it is not much, it is important demonstration of the concept. Goal 4 ------ The fourth goal is to understand the following: .. code:: python def f(cond): y = 3 if cond: x = 1 else: x = 2 return x < y In this we have a branch, and we will be required to keep track of both the branches separately, and then to merge with the original knowledge. After the conditional statement we will know that "x" is an "int" with possible values in ``(1,2)``, which can be used to predict that the return value is always ``True``. The fourth goal will therefore be that the "ValueFriendConstantList" knows that append changes ``a`` value, but it remains a list, and that the size increases by one. It should provide an other value friend "ValueFriendList" for "a" due to that. In order to do that, such code must be considered: .. code:: python a = [] a.append(1) a.append(2) print(len(a)) It will be good, if ``len`` still knows that ``a`` is a list object, but not the constant list anymore. From here, work should be done to demonstrate the correctness of it with the basic tests applied to discover undetected issues. Fifth and optional goal: Extra bonus points for being able to track and predict ``append`` to update the constant list in a known way. Using ``list.append`` that should be done and lead to a constant result of ``len`` being used. The sixth and challenging goal will be to make the code generation be impacted by the value friends types. It should have a knowledge that ``PyList_Append`` does the job of append and use ``PyList_Size`` for ``len``. The "ValueFriends" should aid the code generation too. Last and right now optional goal will be to make ``range`` have a value friend, that can interact with iteration of the for loop, and ``append`` of the ``list`` value friend, so it knows it's possible to iterate 5000 times, and that "a" has then after the "loop" this size, so ``len(a)`` could be predicted. For during the loop, about a the range of its length should be known to be less than 5000. That would make the code of goal 2 completely analyzed at compile time. Limitations for now =================== - Aim only for limited examples. For ``ctypes`` that means to compile time evaluate: .. code:: python print(ctypes.c_int(17) + ctypes.c_long(19)) Later then call to "libc" or something else universally available, e.g. "strlen()" or "strcmp()" from full blown declarations of the callable. - We won't have the ability to test that optimization are actually performed, we will check the generated code by hand. With time, we will add XML based checks with "xpath" queries, expressed as hints, but that is some work that will be based on this work here. The "hints" fits into the "ValueFriends" concept nicely or so the hope is. - No inter-function optimization functions yet Of course, once in place, it will make the ``ctypes`` annotation even more usable. Using ``ctypes`` objects inside functions, while creating them on the module level, is therefore not immediately going to work. - No loops yet Loops break value propagation. For the ``ctypes`` use case, this won't be much of a difficulty. Due to the strangeness of the task, it should be tackled later on at a higher priority. - Not too much. Try and get simple things to work now. We shall see, what kinds of constraints really make the most sense. Understanding ``list`` subscript/slice values e.g. is not strictly useful for much code and should not block us. .. note:: This design is not likely to be the final one. *********************************** How to make Features Experimental *********************************** Every experimental feature needs a name. We have a rule to pick a name with lower case and ``_`` as separators. An example of with would be the name ``jinja_generated_add`` that has been used in the past. Command Line ============ Experimental features are enabled with the command line argument .. code:: bash nuitka --experimental=jinja_generated_add ... In C code ========= In Scons, all experimental features automatically are converted into C defines, and can be used like this: .. code:: C #ifdef _NUITKA_EXPERIMENTAL_JINJA_GENERATED_ADD #include "HelpersOperationGeneratedBinaryAdd.c" #else #include "HelpersOperationBinaryAdd.c" #endif The C pre-processor is the only thing that makes an experimental feature usable. In Python ========= You can query experimental features using ``Options.isExperimental()`` with e.g. code like this: .. code:: python if Options.isExperimental("use_feature"): experimental_code() else: standard_code() When to use it ============== Often we need to keep feature in parallel because they are not finished, or need to be tested after merge and should not break. Then we can do code changes that will not make a difference except when the experimental flag is given on the command line to Nuitka. The testing of Nuitka is very heavy weight when e.g. all Python code is compiled, and very often, it is interesting to compare behavior with and without a change. When to remove it ================= When a feature becomes default, we might choose to keep the old variant around, but normally we do not. Then we remove the ``if`` and ``#if`` checks and drop the old code. At this time, large scale testing will have demonstrated the viability of the code. ******************************* Adding dependencies to Nuitka ******************************* First of all, there is an important distinction to make, run time or development time. The first kind of dependency is used when Nuitka is executing. Adding a Run Time Dependency ============================ This is the kind of dependency that is the most scrutinized. As we want Nuitka to run on latest greatest Python as well as relatively old ones, we have to be very careful with these ones. There is also a distinction of optional dependencies. Right now e.g. the ``lxml`` package is relatively optional, and Nuitka can work without it being installed, because e.g. on some platforms it will not be easy to do so. That bar has lifted somewhat, but it means e.g. that XML based optimization tests are not run with all Python versions. The list of run time dependencies is in ``requirements.txt`` and it is for those the case, that they are not really required to be installed by the user, consider this snippet: .. code:: python # Folders to use for cache files. appdirs # Scons is the backend building tool to turn C files to binaries. scons For both these dependencies, there is either an inline copy (Scons) that we handle to use in case, if Scons is not available (in fact we have a version that works with Python 2.6 and 2.7 still), and also the same for appdirs and every dependency. But since inline copies are against the rules on some platforms that still do not contain the package, we often even have our own wrapper which provides a minimal fallback or exposes a sane interface for the subset of functionality that we use. .. note:: Therefore, please if you consider adding one of these, get in touch with ``@Nuitka-pushers`` first and get a green light. Adding a Development Dependency =============================== A typical example of a development dependency is ``black`` which is used by our autoformat tool, and then in turn by the git pre-commit hook. It is used to format source code, and doesn't have a role at run time of the actual compiler code of Nuitka. Much less strict rules apply to these in comparison to runtime dependencies. Generally please take care that the tool must be well maintained an available on newer Pythons. Then we can use it, no problem normally. But if it's really big, say all of SciPy, we might want to justify it a bit better. The list of development dependencies is in ``requirements-devel.txt`` and it is for example like this: .. code:: python # Autoformat needs this rstfmt == 0.0.10 ; python_version >= '3.7' We always add the version, so that when tests run on as old versions as Python 2.6, the installation would fail with that version, so we need to make a version requirement. Sometimes we use older versions for Python2 than for Python3, ``Jinaj2`` being a notable candidate, but generally we ought to avoid that. For many tools only being available for currently 3.7 or higher is good enough, esp. if they are run as development tools, like ``autoformat-nuitka-source`` is. ********** Idea Bin ********** This an area where to drop random ideas on our minds, to later sort it out, and out it into action, which could be code changes, plan changes, issues created, etc. - Debugging memory leak template, to be added to develop docs .. code:: python # nuitka-project: --follow-import-to=LeakingModule from LeakingModule import main from nuitka.tools.testing.Common import checkReferenceCount checkReferenceCount(main) - Make "SELECT_METACLASS" meta class selection transparent. Looking at the "SELECT_METACLASS" it should become an anonymous helper function. In that way, the optimization process can remove choices at compile time, and e.g. in-line the effect of a meta class, if it is known. This of course makes most sense, if we have the optimizations in place that will allow this to actually happen. - Keeping track of iterations The trace collection trace should become the place, where variables or values track their use state. The iterator should keep track of the "next()" calls made to it, so it can tell which value to given in that case. That would solve the "iteration of constants" as a side effect and it would allow to tell that they can be removed. That would mean to go back in the tree and modify it long after. .. code:: python a = iter((2, 3)) b = next(a) c = next(a) del a It would be sweet if we could recognize that as: .. code:: python a = iter((2, 3)) b = side_effect(next(a), 2) c = side_effect(next(a), 3) del a That trivially becomes: .. code:: python a = iter((2, 3)) next(a) b = 2 next(a) c = 3 del a When the ``del a`` is examined at the end of scope, or due to another assignment to the same variable, ending the trace, we would have to consider of the ``next`` uses, and retrofit the information that they had no effect. .. code:: python a = iter((2, 3)) b = 2 b = 3 del a - Aliasing Each time an assignment is made, an alias is created. A value may have different names. .. code:: python a = iter(range(9)) b = a c = next(b) d = next(a) If we fail to detect the aliasing nature, we will calculate ``d`` wrongly. We may incref and decref values to trace it. Aliasing is automatically traced already in SSA form. The ``b`` is assigned to version of ``a``. So, that should allow to replace it with this: .. code:: python a = iter(range(9)) c = next(a) d = next(a) Which then will be properly handled. - Tail recursion optimization. Functions that return the results of calls, can be optimized. The Stackless Python does it already. - Integrate with "upx" compression. Calling "upx" on the created binaries, would be easy. - In-lining constant "exec" and "eval". It should be possible to re-formulate at least cases without "locals" or "globals" given. .. code:: python def f(): a = 1 b = 2 exec("""a+=b;c=1""") return a, c Should become this here: .. code:: python def f(): a = 1 b = 2 a += b # c = 1 # MaybeLocalVariables for everything except known local ones. return a, c If this holds up, inlining ``exec`` should be relatively easy. - Original and overloaded built-ins This is about making things visible in the node tree. In Nuitka things that are not visible in the node tree tend to be wrong. We already pushed around information to the node tree a lot. Later versions, Nuitka will become able to determine it has to be the original built-in at compile time, then a condition that checks will be optimized away, together with the slow path. Or the other path, if it won't be. Then it will be optimized away, or if doubt exists, it will be correct. That is the goal. Right now, the change would mean to effectively disable all built-in call optimization, which is why we don't immediately do it. Making the compatible version, will also require a full listing of all built-ins, which is typing work merely, but not needed now. And a way to stop built-in optimization from optimizing built-in calls that it used in a wrap. Probably just some flag to indicate it when it visits it to skip it. That's for later. But should we have that both, I figure, we could not raise a ``RuntimeError`` error, but just do the correct thing, in all cases. An earlier step may raise ``RuntimeError`` error, when built-in module values are written to, that we don't support. ****************** Prongs of Action ****************** In this chapter, we keep track of prongs of action currently ongoing. This can get detailed and shows things we strive for. Builtin optimization ==================== Definitely want to get built-in names under full control, so that variable references to module variables do not have a twofold role. Currently they reference the module variable and also the potential built-in as a fallback. In terms of generated code size and complexity for modules with many variables and uses of them that is horrible. But ``some_var`` (normally) cannot be a built-in and therefore needs no code to check for that each time. This is also critical to getting to whole program optimization. Being certain what is what there on module level, will enable more definitely knowledge about data flows and module interfaces. Class Creation Overhead Reduction ================================= This is more of a meta goal. Some work for the metaclass has already been done, but that is Python2 only currently. Being able to to decide built-ins and to distinguish between global only variables, and built-ins more clearly will help this a lot. In the end, empty classes should be able to be statically converted to calls to ``type`` with static dictionaries. The inlining of class creation function is also needed for this, but on Python3 cannot happen yet. Memory Usage at Compile Time ============================ We will need to store more and more information in the future. Getting the tree to be tight shaped is therefore an effort, where we will be spending time too. The mix-ins prevent slots usage, so lets try and get rid of those. The "children having" should become more simple and faster code. I am even thinking of even generating code in the meta class, so it's both optimal and doesn't need that mix-in any more. This is going to be ugly then. Coverage Testing ================ And then there is coverage, it should be taken and merged from all Python versions and OSes, but I never managed to merge between Windows and Linux for unknown reasons. Python3 Performance =================== The Python3 lock for thread state is making it slower by a lot. I have only experimental code that just ignores the lock, but it likely only works on Linux, and I wonder why there is that lock in the first place. Ignoring the locks cannot be good. But what updates that thread state pointer ever without a thread change, and is this what ABI flags are about in this context, are there some that allow us to ignore the locks. An important bit would be to use a thread state once acquired for as much as possible, currently exception helpers do not accept it as an argument, but that ought to become an option, that way saving and restoring an exception will be much faster, not to mention checking and dropping non interesting, or rewriting exceptions. Caching of Python level compilation =================================== While the C compilation result is already cached with `ccache` and friends now, we need to also cover our bases and save the resulting node tree of potential expensive optimization on the module level. ************************* Updates for this Manual ************************* This document is written in REST. That is an ASCII format which is readable to human, but easily used to generate PDF or HTML documents. You will find the current source under: https://github.com/Nuitka/Nuitka/blob/develop/Developer_Manual.rst And the current PDF under: https://nuitka.net/doc/Developer_Manual.pdf ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/LICENSE.txt0000644000175100017520000002612415063223176020572 0ustar00nuitka-buildslavenuitka-buildslave Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright © 2010-2019 Kay Hayen Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/MANIFEST.in0000644000175100017520000000332515063223176020503 0ustar00nuitka-buildslavenuitka-buildslave# Spell checking makes no sense, spell-checker: disable include LICENSE.txt include MANIFEST.in include README.rst include Changelog.rst include Developer_Manual.rst include doc/nuitka.1 include doc/nuitka-run.1 include bin/compare_with_cpython include bin/compare_with_xml include bin/check-nuitka-with-pylint include bin/autoformat-nuitka-source include bin/measure-construct-performance # Runners, mainly for source distribution. include bin/nuitka include bin/nuitka-run include misc/*.cmd include tests/run-tests include nuitka/plugins/standard/*.yml # Logo with source include doc/Logo/Nuitka-Logo-Symbol.svg include doc/Logo/Nuitka-Logo-Vertical.svg include doc/Logo/Nuitka-Logo-Horizontal.svg include doc/images/Nuitka-Logo-Symbol.png include doc/images/Nuitka-Logo-Vertical.png include doc/images/Nuitka-Logo-Horizontal.png recursive-include lib *.py # Core tests are included along with Nuitka itself. recursive-include tests/basics *.py recursive-include tests/syntax *.py recursive-include tests/packages *.py recursive-include tests/programs *.py include tests/programs/pkgutil_usage/package/DATA_FILE*.txt include tests/programs/resource_reader37/some_package/DATA_FILE*.txt include tests/onefile/external-data/*.txt recursive-include tests/optimizations *.py recursive-include tests/standalone *.py recursive-include tests/onefile *.py recursive-include tests/reflected *.py recursive-include tests/plugins *.py recursive-include tests/plugins *.yml include tests/plugins/data_files/data_files_package/*.txt include tests/plugins/data_files/data_files_package/sub_dir/*.txt # C templates for code generation. recursive-include nuitka/code_generation/templates_c *.j2 # Report templates recursive-include nuitka/reports *.j2 ././@PaxHeader0000000000000000000000000000003400000000000010212 xustar0028 mtime=1758275202.3802621 Nuitka-2.7.16/Nuitka.egg-info/0000700000175100017520000000000015063223202021643 5ustar00nuitka-buildslavenuitka-buildslave././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275202.0 Nuitka-2.7.16/Nuitka.egg-info/PKG-INFO0000600000175100017520000024473015063223202022754 0ustar00nuitka-buildslavenuitka-buildslaveMetadata-Version: 2.1 Name: Nuitka Version: 2.7.16 Summary: Python compiler with full language support and CPython compatibility Home-page: https://nuitka.net Author: Kay Hayen Author-email: Kay.Hayen@gmail.com License: Apache License, Version 2.0 Project-URL: Commercial, https://nuitka.net/doc/commercial.html Project-URL: Support, https://nuitka.net/pages/support.html Project-URL: Documentation, https://nuitka.net/doc/user-manual.html Project-URL: Donations, https://nuitka.net/pages/donations.html Project-URL: Mastodon, https://fosstodon.org/@kayhayen Project-URL: Twitter, https://twitter.com/KayHayen Project-URL: Source, https://github.com/Nuitka/Nuitka Keywords: compiler,python,nuitka Classifier: Development Status :: 5 - Production/Stable Classifier: Intended Audience :: Developers Classifier: Intended Audience :: Science/Research Classifier: Topic :: Software Development :: Compilers Classifier: Topic :: Software Development :: Build Tools Classifier: Topic :: Software Development :: Quality Assurance Classifier: Topic :: System :: Software Distribution Classifier: Programming Language :: Python :: 3.13 Classifier: Programming Language :: Python :: 3.12 Classifier: Programming Language :: Python :: 3.11 Classifier: Programming Language :: Python :: 3.10 Classifier: Programming Language :: Python :: 3.9 Classifier: Programming Language :: Python :: 3.8 Classifier: Programming Language :: Python :: 3.7 Classifier: Programming Language :: Python :: 3.6 Classifier: Programming Language :: Python :: 3.5 Classifier: Programming Language :: Python :: 3.4 Classifier: Programming Language :: Python :: 2.7 Classifier: Programming Language :: Python :: 2.6 Classifier: Programming Language :: Python :: Implementation :: CPython Classifier: Programming Language :: C Classifier: Operating System :: POSIX :: Linux Classifier: Operating System :: POSIX :: BSD :: FreeBSD Classifier: Operating System :: POSIX :: BSD :: NetBSD Classifier: Operating System :: POSIX :: BSD :: OpenBSD Classifier: Operating System :: Microsoft :: Windows Classifier: Operating System :: MacOS Classifier: Operating System :: Android Classifier: License :: OSI Approved :: Apache Software License Description-Content-Type: text/x-rst Provides-Extra: build-wheel License-File: LICENSE.txt .. image:: https://img.shields.io/pypi/pyversions/Nuitka.svg :target: https://pypi.org/project/Nuitka .. image:: https://badge.fury.io/py/Nuitka.svg :target: https://pypi.org/project/Nuitka .. image:: https://img.shields.io/badge/Contributor%20Covenant-v1.4%20adopted-ff69b4.svg :target: CODE_OF_CONDUCT.md #################### Nuitka User Manual #################### This document is the recommended first read when you start using **Nuitka**. On this page, you will learn more about **Nuitka** fundamentals, such as license type, use cases, requirements, and credits. .. contents:: Table of Contents :depth: 1 :local: :class: page-toc Nuitka is **the** Python compiler. It is written in Python. It is a seamless replacement or extension to the Python interpreter and compiles **every** construct that Python 2 (2.6, 2.7) and Python 3 (3.4 - 3.13) have, when itself run with that Python version. It then executes uncompiled code and compiled code together in an extremely compatible manner. You can use all Python library modules and all extension modules freely. Nuitka translates the Python modules into a C level program that then uses ``libpython`` and static C files of its own to execute in the same way as CPython does. All optimization is aimed at avoiding overhead, where it's unnecessary. None is aimed at removing compatibility, although slight improvements will occasionally be done, where not every bug of standard Python is emulated, e.g. more complete error messages are given, but there is a full compatibility mode to disable even that. ************** Requirements ************** To ensure smooth operation of **Nuitka**, make sure to follow system requirements, that include the following components: :depth: 1 :local: C Compiler ========== You need a C compiler with support for C11 or alternatively a C++ compiler for C++03 [#]_. Currently, this means, you need to use one of these compilers: - The MinGW64 C11 compiler, on Windows, must be based on gcc 11.2 or higher. It will be *automatically* downloaded if no usable C compiler is found, which is the recommended way of installing it, as Nuitka will also upgrade it for you. - Visual Studio 2022 or higher on Windows [#]_. English language pack for best results (Nuitka filters away garbage outputs, but only for English language). It will be used by default if installed. - On all other platforms, the ``gcc`` compiler of at least version 5.1, and below that the ``g++`` compiler of at least version 4.4 as an alternative. - The ``clang`` compiler on macOS X and most FreeBSD architectures. - On Windows, the ``clang-cl`` compiler on Windows can be used if provided by the Visual Studio installer. .. [#] Support for this C11 is given with gcc 5.x or higher or any clang version. The older MSVC compilers don't do it yet. But as a workaround, with Python 3.10 or older, the C++03 language standard is significantly overlapping with C11, it is then used instead. .. [#] Download for free from https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx (the community editions work just fine). The latest version is recommended, but not required. On the other hand, there is no need to except to support pre-Windows 10 versions, and they might work for you, but support of these configurations is only available to commercial users. Python ====== **Python 2** (2.6, 2.7) and **Python 3** (3.4 — 3.13) are supported. If at any moment, there is a stable Python release that is not in this list, rest assured it is being worked on and will be added. .. important:: For Python 3.4 and *only* that version, we need other Python version as a *compile time* dependency. Nuitka itself is fully compatible with all listed versions, but Scons as an internally used tool is not. For these versions, you *need* a Python2 or Python 3.5 or higher installed as well, but only during the compile time. That is for use with Scons (which orchestrates the C compilation), which does not support the same Python versions as Nuitka. In addition, on Windows, Python2 cannot be used because ``clcache`` does not work with it, there a Python 3.5 or higher needs to be installed. Nuitka finds these needed Python versions (e.g. on Windows via registry) and you shouldn't notice it as long as they are installed. Increasingly, other functionality is available when another Python has a certain package installed. For example, onefile compression will work for a Python 2.x when another Python is found that has the ``zstandard`` package installed. .. admonition:: Moving binaries to other machines The created binaries can be made executable independent of the Python installation, with ``--standalone`` and ``--onefile`` options. .. admonition:: Binary filename suffix The created binaries have an ``.exe`` suffix on Windows. On other platforms they have no suffix for standalone mode, or ``.bin`` suffix, that you are free to remove or change, or specify with the ``-o`` option. The suffix for acceleration mode is added just to be sure that the original script name and the binary name do not ever collide, so we can safely overwrite the binary without destroying the original source file. .. admonition:: It **has to** be CPython, Anaconda Python, or Homebrew You need the standard Python implementation, called "CPython", to execute Nuitka because it is closely tied to implementation details of it. .. admonition:: It **cannot be** from the Windows app store It is known that Windows app store Python definitely does not work, it's checked against. .. admonition:: It **cannot be** pyenv on macOS It is known that macOS "pyenv" does **not** work. Use Homebrew instead for self compiled Python installations. But note that standalone mode will be worse on these platforms and not be as backward compatible with older macOS versions. Operating System ================ Supported Operating Systems: Linux, FreeBSD, NetBSD, macOS, and Windows (32 bits/64 bits/ARM). Others will work as well. The portability is expected to be generally good, but the e.g. Nuitka's internal Scons usage may have to be adapted or need flags passed. Make sure to match Python and C compiler architecture, or else you will get cryptic error messages. Architecture ============ Supported Architectures are x86, x86_64 (amd64), and arm, likely many, many more. Other architectures are expected to also work, out of the box, as Nuitka is generally not using any hardware specifics. These are just the ones tested and known to be good. Feedback is welcome. Generally, the architectures that Debian supports can be considered good and tested, too. ******* Usage ******* Command Line ============ The recommended way of executing Nuitka is `` -m nuitka`` to be absolutely certain which Python interpreter you are using, so it is easier to match with what Nuitka has. The next best way of executing Nuitka bare that is from a source checkout or archive, with no environment variable changes, most noteworthy, you do not have to mess with ``PYTHONPATH`` at all for Nuitka. You just execute the ``nuitka`` and ``nuitka-run`` scripts directly without any changes to the environment. You may want to add the ``bin`` directory to your ``PATH`` for your convenience, but that step is optional. Moreover, if you want to execute with the right interpreter, in that case, be sure to execute `` bin/nuitka`` and be good. .. admonition:: Pick the right Interpreter If you encounter a ``SyntaxError`` you absolutely most certainly have picked the wrong interpreter for the program you are compiling. Nuitka has a ``--help`` option to output what it can do: .. code:: bash nuitka --help The ``nuitka-run`` command is the same as ``nuitka``, but with a different default. It tries to compile *and* directly execute a Python script: .. code:: bash nuitka-run --help This option that is different is ``--run``, and passing on arguments after the first non-option to the created binary, so it is somewhat more similar to what plain ``python`` will do. Installation ============ For most systems, there will be packages on the `download page `__ of Nuitka. But you can also install it from source code as described above, but also like any other Python program it can be installed via the normal ``python setup.py install`` routine. Notice for integration with GitHub workflows there is this `Nuitka-Action `__ that you should use that makes it really easy to integrate. You ought to start with a local compilation though, but this will be easiest for cross platform compilation with Nuitka. License ======= Nuitka is licensed under the Apache License, Version 2.0; you may not use it except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ************************************* Tutorial Setup and build on Windows ************************************* This is basic steps if you have nothing installed, of course if you have any of the parts, just skip it. Setup ===== Install Python -------------- - Download and install Python from https://www.python.org/downloads/windows - Select one of ``Windows x86-64 web-based installer`` (64 bits Python, recommended) or ``x86 executable`` (32 bits Python) installer. - Verify it's working using command ``python --version``. Install Nuitka -------------- - ``python -m pip install nuitka`` - Verify using command ``python -m nuitka --version`` Write some code and test ======================== Create a folder for the Python code ----------------------------------- - ``mkdir`` HelloWorld - make a python file named **hello.py** .. code:: python def talk(message): return "Talk " + message def main(): print(talk("Hello World")) if __name__ == "__main__": main() Test your program ----------------- Do as you normally would. Running Nuitka on code that works incorrectly is not easier to debug. .. code:: bash python hello.py ---- Build it using -------------- .. code:: bash python -m nuitka hello.py .. note:: This will prompt you to download a C caching tool (to speed up repeated compilation of generated C code) and a MinGW64 based C compiler, unless you have a suitable MSVC installed. Say ``yes`` to both those questions. Run it ------ Execute the ``hello.exe`` created near ``hello.py``. Distribute ---------- To distribute, build with ``--standalone`` option, which will not output a single executable, but a whole folder. Copy the resulting ``hello.dist`` folder to the other machine and run it. You may also try ``--onefile`` which does create a single file, but make sure that the mere standalone is working, before turning to it, as it will make the debugging only harder, e.g. in case of missing data files. *********** Use Cases *********** Use Case 1 — Program compilation with all modules embedded ============================================================ If you want to compile a whole program recursively, and not only the single file that is the main program, do it like this: .. code:: bash python -m nuitka --follow-imports program.py .. note:: There are more fine-grained controls than ``--follow-imports`` available. Consider the output of ``nuitka --help``. Including fewer modules into the compilation, but instead using normal Python for it, will make it faster to compile. In case you have a source directory with dynamically loaded files, i.e. one which cannot be found by recursing after normal import statements via the ``PYTHONPATH`` (which would be the recommended way), you can always require that a given directory shall also be included in the executable: .. code:: bash python -m nuitka --follow-imports --include-plugin-directory=plugin_dir program.py .. note:: If you don't do any dynamic imports, simply setting your ``PYTHONPATH`` at compilation time is what you should do. Use ``--include-plugin-directory`` only if you make ``__import__()`` calls that Nuitka cannot predict, and that come from a directory, for everything from your Python installation, use ``--include-module`` or ``--include-package``. .. note:: The resulting filename will be ``program.exe`` on Windows, ``program.bin`` on other platforms, but ``--output-filename`` allows changing that. .. note:: The resulting binary still depends on CPython and used C extension modules being installed. If you want to be able to copy it to another machine, use ``--standalone`` and copy the created ``program.dist`` directory and execute the ``program.exe`` (Windows) or ``program`` (other platforms) put inside. Use Case 2 — Extension Module compilation =========================================== If you want to compile a single extension module, all you have to do is this: .. code:: bash python -m nuitka --mode=module some_module.py The resulting file ``some_module.so`` can then be used instead of ``some_module.py``. .. important:: The filename of the produced extension module must not be changed as Python insists on a module name derived function as an entry point, in this case ``PyInit_some_module`` and renaming the file will not change that. Match the filename of the source code to what the binary name should be. .. note:: If both the extension module and the source code of it are in the same directory, the extension module is loaded. Changes to the source code only have effect once you recompile. .. note:: The option ``--follow-import-to`` works as well, but the included modules will only become importable *after* you imported the ``some_module`` name. If these kinds of imports are invisible to Nuitka, e.g. dynamically created, you can use ``--include-module`` or ``--include-package`` in that case, but for static imports it should not be needed. .. note:: An extension module can never include other extension modules. You will have to create a wheel for this to be doable. .. note:: The resulting extension module can only be loaded into a CPython of the same version and doesn't include other extension modules. Use Case 3 — Package compilation ================================== If you need to compile a whole package and embed all modules, that is also feasible, use Nuitka like this: .. code:: bash python -m nuitka --mode=module some_package --include-package=some_package .. note:: The inclusion of the package contents needs to be provided manually; otherwise, the package is mostly empty. You can be more specific if you like, and only include part of it, or exclude part of it, e.g. with ``--nofollow-import-to='*.tests'`` you would not include the unused test part of your code. .. note:: Data files located inside the package will not be embedded by this process, you need to copy them yourself with this approach. Alternatively, you can use the `file embedding of Nuitka commercial `__. Use Case 4 — Program Distribution =================================== For distribution to other systems, there is the standalone mode, which produces a folder for which you can specify ``--standalone``. .. code:: bash python -m nuitka --standalone program.py Following all imports is default in this mode. You can selectively exclude modules by specifically saying ``--nofollow-import-to``, but then an ``ImportError`` will be raised when import of it is attempted at program run time. This may cause different behavior, but it may also improve your compile time if done wisely. For data files to be included, use the option ``--include-data-files==`` where the source is a file system path, but the target has to be specified relative. For the standalone mode, you can also copy them manually, but this can do extra checks, and for the onefile mode, there is no manual copying possible. To copy some or all file in a directory, use the option ``--include-data-files=/etc/*.txt=etc/`` where you get to specify shell patterns for the files, and a subdirectory where to put them, indicated by the trailing slash. .. important:: Nuitka does not consider data files code, do not include DLLs, or Python files as data files, and expect them to work, they will not, unless you really know what you are doing. In the following, non-code data files are all files, not matching on of these criterions. +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | Suffix | Rationale | Solution | +============+========================================================================================+========================================================================================================+ | ``.py`` | Nuitka trims even the stdlib modules to be included. If it doesn't see Python code, | Use ``--include-module`` on them instead | | | there is no dependencies analyzed, and as a result it will just not work. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyc`` | Same as ``.py``. | Use ``--include-module`` on them from their source code instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyo`` | Same as ``.pyc``. | Use ``--include-module`` on them from their source code instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyw`` | Same as ``.py``. | For including multiple programs, use multiple ``--main`` arguments instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyi`` | These are ignored, because they are code-like and not needed at run time. For the | Raise an issue if 3rd part software needs it. | | | ``lazy`` package that actually would depend on them, we made a compile time solution | | | | that removes the need. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyx`` | These are ignored, because they are Cython source code not used at run time | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.dll`` | These are ignored, since they **usually** are not data files. For the cases where 3rd | Create Nuitka Package configuration for those, with ``dll`` section for the package that uses them. | | | party packages do actually used them as data, e.g. ``.NET`` packages, we solve that in | For rare cases, data-files section with special configuration might be the correct thing to do. | | | package configuration for it. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.dylib`` | These are ignored, since they macOS extension modules or DLLs. | Need to add configuration with ``dll`` section or ``depends`` that are missing | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.so`` | These are ignored, since they Linux, BSD, etc. extension modules or DLLs. | Need to add configuration with ``dll`` section or ``depends`` that are missing | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.exe`` | The are binaries to Windows. | You can add Nuitka Package configuration to include those as DLLs and mark them as ``executable: yes`` | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.bin`` | The are binaries to non-Windows, otherwise same as ``.exe``. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ Also folders are ignored, these are ``site-packages``, ``dist-packages`` and ``vendor-packages`` which would otherwise include a full virtualenv, which is never a good thing to happen. And the ``__pycache__`` folder is also always ignored. On non-MacOS the file ``.DS_Store`` is ignored too, and ``py.typed`` folders have only meaning to IDEs, and are ignored like ``.pyi`` files . To copy a whole folder with all non-code files, you can use ``--include-data-dir=/path/to/images=images`` which will place those in the destination, and if you want to use the ``--noinclude-data-files`` option to remove them. Code files are as detailed above DLLs, executables, Python files, etc. and will be ignored. For those you can use the ``--include-data-files=/binaries/*.exe=binary/`` form to force them, but that is not recommended and known to cause issues at run-time. For package data, there is a better way, namely using ``--include-package-data``, which detects all non-code data files of packages automatically and copies them over. It even accepts patterns in a shell style. It spares you the need to find the package directory yourself and should be preferred whenever available. Functionally it's very similar to ``--include-data-dir`` but it has the benefit to locate the correct folder for you. With data files, you are largely on your own. Nuitka keeps track of ones that are needed by popular packages, but it might be incomplete. Raise issues if you encounter something in these. Even better, raise PRs with enhancements to the Nuitka package configuration. We want 3rd party software to just work out of the box. When that is working, you can use the onefile mode if you so desire. .. code:: bash python -m nuitka --onefile program.py This will create a single binary, that extracts itself on the target, before running the program. But notice, that accessing files relative to your program is impacted, make sure to read the section `Onefile: Finding files`_ as well. .. code:: bash # Create a binary that unpacks into a temporary folder python -m nuitka --onefile program.py .. note:: There are more platform-specific options, e.g. related to icons, splash screen, and version information, consider the ``--help`` output for the details of these and check the section Tweaks_. For the unpacking, by default a unique user temporary path one is used, and then deleted, however this default ``--onefile-tempdir-spec="{TEMP}/onefile_{PID}_{TIME}"`` can be overridden with a path specification, then using a cached path, avoiding repeated unpacking, e.g. with ``--onefile-tempdir-spec="{CACHE_DIR}/{COMPANY}/{PRODUCT}/{VERSION}"`` which uses version information, and user-specific cache directory. .. note:: Using cached paths will be relevant, e.g. when Windows Firewall comes into play because otherwise, the binary will be a different one to it each time it is run. Currently, these expanded tokens are available: +----------------+-----------------------------------------------------------+---------------------------------------+ | Token | What this Expands to | Example | +================+===========================================================+=======================================+ | {TEMP} | User temporary file directory | C:\\Users\\...\\AppData\\Locals\\Temp | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PID} | Process ID | 2772 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {TIME} | Time in seconds since the epoch. | 1299852985 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM} | Full program run-time filename of executable. | C:\\SomeWhere\\YourOnefile.exe | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM_BASE} | No-suffix of run-time filename of executable. | C:\\SomeWhere\\YourOnefile | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM_DIR} | Containing directory of executable. | C:\\SomeWhere | +----------------+-----------------------------------------------------------+---------------------------------------+ | {CACHE_DIR} | Cache directory for the user. | C:\\Users\\SomeBody\\AppData\\Local | +----------------+-----------------------------------------------------------+---------------------------------------+ | {COMPANY} | Value given as ``--company-name`` | YourCompanyName | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PRODUCT} | Value given as ``--product-name`` | YourProductName | +----------------+-----------------------------------------------------------+---------------------------------------+ | {VERSION} | Combination of ``--file-version`` & ``--product-version`` | 3.0.0.0-1.0.0.0 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {HOME} | Home directory for the user. | /home/somebody | +----------------+-----------------------------------------------------------+---------------------------------------+ | {NONE} | When provided for file outputs, ``None`` is used | see notice below | +----------------+-----------------------------------------------------------+---------------------------------------+ | {NULL} | When provided for file outputs, ``os.devnull`` is used | see notice below | +----------------+-----------------------------------------------------------+---------------------------------------+ .. important:: It is your responsibility to make the path provided unique, on Windows a running program will be locked, and while using a fixed folder name is possible, it can cause locking issues in that case, where the program gets restarted. Usually, you need to use ``{TIME}`` or at least ``{PID}`` to make a path unique, and this is mainly intended for use cases, where e.g. you want things to reside in a place you choose or abide your naming conventions. .. important:: For disabling output and stderr with ``--force-stdout-spec`` and ``--force-stderr-spec`` the values ``{NONE}`` and ``{NULL}`` achieve it, but with different effect. With ``{NONE}``, the corresponding handle becomes ``None``. As a result, e.g. ``sys.stdout`` will be ``None``, which is different from ``{NULL}`` where it will be backed by a file pointing to ``os.devnull``, i.e. you can write to it. With ``{NONE}``, you may e.g. get ``RuntimeError: lost sys.stdout`` in case it does get used; with ``{NULL}`` that never happens. However, some libraries handle this as input for their logging mechanism, and on Windows this is how you are compatible with ``pythonw.exe`` which is behaving like ``{NONE}``. Use Case 5 — Setuptools Wheels ================================ If you have a ``setup.py``, ``setup.cfg`` or ``pyproject.toml`` driven creation of wheels for your software in place, putting Nuitka to use is extremely easy. Let's start with the most common ``setuptools`` approach, you can, having Nuitka installed of course, simply execute the target ``bdist_nuitka`` rather than the ``bdist_wheel``. It takes all the options and allows you to specify some more, that are specific to Nuitka. .. code:: python # For setup.py if you don't use other build systems: setup( # Data files are to be handled by setuptools and not Nuitka package_data={"some_package": ["some_file.txt"]}, ..., # This is to pass Nuitka options. command_options={ 'nuitka': { # boolean option, e.g. if you cared for C compilation commands '--show-scons': True, # options without value, e.g. enforce using Clang '--clang': None, # options with single values, e.g. enable a plugin of Nuitka '--enable-plugin': "pyside2", # options with several values, e.g. avoid including modules '--nofollow-import-to' : ["*.tests", "*.distutils"], }, }, ) # For setup.py with other build systems: # The tuple nature of the arguments is required by the dark nature of # "setuptools" and plugins to it, that insist on full compatibility, # e.g. "setuptools_rust" setup( # Data files are to be handled by setuptools and not Nuitka package_data={"some_package": ["some_file.txt"]}, ..., # This is to pass Nuitka options. ..., command_options={ 'nuitka': { # boolean option, e.g. if you cared for C compilation commands '--show-scons': ("setup.py", True), # options without value, e.g. enforce using Clang '--clang': ("setup.py", None), # options with single values, e.g. enable a plugin of Nuitka '--enable-plugin': ("setup.py", "pyside2"), # options with several values, e.g. avoid including modules '--nofollow-import-to' : ("setup.py", ["*.tests", "*.distutils"]), } }, ) If for some reason, you cannot or do not want to change the target, you can add this to your ``setup.py``. .. code:: python # For setup.py setup( ..., build_with_nuitka=True ) .. note:: To temporarily disable the compilation, you could the remove above line, or edit the value to ``False`` by or take its value from an environment variable if you so choose, e.g. ``bool(os.getenv("USE_NUITKA", "True"))``. This is up to you. Or you could put it in your ``setup.cfg`` .. code:: toml [metadata] build_with_nuitka = true And last, but not least, Nuitka also supports the new ``build`` meta, so when you have a ``pyproject.toml`` already, simple replace or add this value: .. code:: toml [build-system] requires = ["setuptools>=42", "wheel", "nuitka", "toml"] build-backend = "nuitka.distutils.Build" # Data files are to be handled by setuptools and not Nuitka [tool.setuptools.package-data] some_package = ['data_file.txt'] [tool.nuitka] # These are not recommended, but they make it obvious to have effect. # boolean option, e.g. if you cared for C compilation commands, leading # dashes are omitted show-scons = true # options with single values, e.g. enable a plugin of Nuitka enable-plugin = "pyside2" # options with several values, e.g. avoid including modules, accepts # list argument. nofollow-import-to = ["*.tests", "*.distutils"] .. note:: For the ``nuitka`` requirement above absolute paths like ``C:\Users\...\Nuitka`` will also work on Linux, use an absolute path with *two* leading slashes, e.g. ``//home/.../Nuitka``. .. note:: Whatever approach you take, data files in these wheels are not handled by Nuitka at all, but by setuptools. You can, however, use the data file embedding of Nuitka commercial. In that case, you actually would embed the files inside the extension module itself, and not as a file in the wheel. Use Case 6 — Multidist ======================== If you have multiple programs, that each should be executable, in the past you had to compile multiple times, and deploy all of these. With standalone mode, this, of course, meant that you were fairly wasteful, as sharing the folders could be done, but wasn't really supported by Nuitka. Enter ``Multidist``. There is an option ``--main`` that replaces or adds to the positional argument given. And it can be given multiple times. When given multiple times, Nuitka will create a binary that contains the code of all the programs given, but sharing modules used in them. They therefore do not have to be distributed multiple times. Let's call the basename of the main path, and entry point. The names of these must, of course, be different. Then the created binary can execute either entry point, and will react to what ``sys.argv[0]`` appears to it. So if executed in the right way (with something like ``subprocess`` or OS API you can control this name), or by renaming or copying the binary, or symlinking to it, you can then achieve the miracle. This allows to combine very different programs into one. .. note:: This feature is still experimental. Use with care and report your findings should you encounter anything that is undesirable behavior This mode works with standalone, onefile, and mere acceleration. It does not work with module mode. Use Case 7 — Building with GitHub Workflows ============================================= For integration with GitHub workflows there is this `Nuitka-Action `__ that you should use that makes it really easy to integrate. You ought to start with a local compilation though, but this will be easiest for cross platform compilation with Nuitka. This is an example workflow that builds on all 3 OSes .. code:: yaml jobs: build: strategy: matrix: os: [macos-latest, ubuntu-latest, windows-latest] runs-on: ${{ matrix.os }} steps: - name: Check-out repository uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: '3.10' cache: 'pip' cache-dependency-path: | **/requirements*.txt - name: Install your Dependencies run: | pip install -r requirements.txt -r requirements-dev.txt - name: Build Executable with Nuitka uses: Nuitka/Nuitka-Action@main with: nuitka-version: main script-name: your_main_program.py # many more Nuitka options available, see action doc, but it's best # to use nuitka-project: options in your code, so e.g. you can make # a difference for macOS and create an app bundle there. mode: onefile - name: Upload Artifacts uses: actions/upload-artifact@v4 with: name: ${{ runner.os }} Build path: | # match what's created for the 3 OSes build/*.exe build/*.bin build/*.app/**/* If you app is a GUI, e.g. ``your_main_program.py`` should contain these comments as explained in `Nuitka Options in the code`_ since on macOS this should then be a bundle. .. code:: python # Compilation mode, standalone everywhere, except on macOS there app bundle # nuitka-project-if: {OS} in ("Windows", "Linux", "FreeBSD"): # nuitka-project: --onefile # nuitka-project-if: {OS} == "Darwin": # nuitka-project: --standalone # nuitka-project: --macos-create-app-bundle # .. note:: This is best expression with ``nuitka-project: --mode=app`` which encapsulates these options. ******** Tweaks ******** Icons ===== For good looks, you may specify icons. On Windows, you can provide an icon file, a template executable, or a PNG file. All of these will work and may even be combined: .. code:: bash # These create binaries with icons on Windows python -m nuitka --onefile --windows-icon-from-ico=your-icon.png program.py python -m nuitka --onefile --windows-icon-from-ico=your-icon.ico program.py python -m nuitka --onefile --windows-icon-template-exe=your-icon.ico program.py # These create application bundles with icons on macOS python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.png program.py python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.icns program.py .. note:: With Nuitka, you do not have to create platform-specific icons, but instead it will convert e.g. PNG, but also other formats on the fly during the build. MacOS Entitlements ================== Entitlements for an macOS application bundle can be added with the option, ``--macos-app-protected-resource``, all values are listed on `this page from Apple `__ An example value would be ``--macos-app-protected-resource=NSMicrophoneUsageDescription:Microphone access`` for requesting access to a Microphone. After the colon, the descriptive text is to be given. .. note:: Beware that in the likely case of using spaces in the description part, you need to quote it for your shell to get through to Nuitka and not be interpreted as Nuitka arguments. Console Window ============== On Windows, the console is not opened by programs unless you say so. Nuitka defaults to not show it, you can force it by using ``--console=force`` though, then the program will open a new terminal Window when its executed. Splash screen ============= Splash screens are useful when program startup is slow. Onefile startup itself is not slow, but your program may be, and you cannot really know how fast the computer used will be, so it might be a good idea to have them. Luckily, with Nuitka, they are easy to add for Windows. For the splash screen, you need to specify it as a PNG file, and then make sure to disable the splash screen when your program is ready, e.g. has completed the imports, prepared the window, connected to the database, and wants the splash screen to go away. Here we are using the project syntax to combine the code with the creation, compile this: .. code:: python # nuitka-project: --mode=onefile # nuitka-project: --mode=onefile-windows-splash-screen-image={MAIN_DIRECTORY}/Splash-Screen.png # Whatever this is, obviously print("Delaying startup by 10s...") import time, tempfile, os time.sleep(10) # Use this code to signal the splash screen removal. if "NUITKA_ONEFILE_PARENT" in os.environ: splash_filename = os.path.join( tempfile.gettempdir(), "onefile_%d_splash_feedback.tmp" % int(os.environ["NUITKA_ONEFILE_PARENT"]), ) if os.path.exists(splash_filename): os.unlink(splash_filename) print("Done... splash should be gone.") ... # Rest of your program goes here. Reports ======= For analysis of your program and Nuitka packaging, there is the `Compilation Report`_ available. You can also make custom reports by providing your template, with a few of them built-in to Nuitka. These reports carry all the detail information, e.g. when a module was attempted to be imported, but not found, you can see where that happens. For bug reporting, it is very much recommended to provide the report. Version Information =================== You can attach copyright and trademark information, company name, product name, and so on to your compilation. This is then used in version information for the created binary on Windows, or application bundle on macOS. If you find something that is lacking, please let us know. ****************** Typical Problems ****************** Deployment Mode =============== By default, Nuitka compiles without ``--deployment`` which leaves a set of safe guards and helpers on, that are aimed at debugging wrong uses of Nuitka. This is a new feature, and implements a bunch of protections and helpers, that are documented here. Fork bombs (self-execution) --------------------------- So after compilation, ``sys.executable`` is the compiled binary. In case of packages like ``multiprocessing``, ``joblib``, or ``loky`` what these typically do is to expect to run from a full ``python`` with ``sys.executable`` and then to be able to use its options like ``-c command`` or ``-m module_name`` and then be able to launch other code temporarily or permanently as a service daemon. With Nuitka however, this executes your program again, and puts these arguments, in ``sys.argv`` where you maybe ignore them, and then you fork yourself again to launch the helper daemons. Sometimes this ends up spawning CPU count processes that spawn CPU count processes that... this is called a fork bomb, and with almost all systems, that freezes them easily to death. That is why e.g. this happens with default Nuitka: .. code:: ./hello.dist/hello.bin -l fooL -m fooM -n fooN -o fooO -p Error, the program tried to call itself with '-m' argument. Disable with '--no-deployment-flag=self-execution'. Your program may well have its own command line parsing, and not use an unsupported package that does attempt to re-execute. In this case, you need at *compile time* to use ``--no-deployment-flag=self-execution`` which disables this specific guard. Misleading Messages ------------------- Some packages output what they think is helpful information about what the reason of a failed import might mean. With compiled programs there are very often just plain wrong. We try and repair those in non-deployment mode. Here is an example, where we change a message that asks to pip install (which is not the issue) to point the user to the include command that makes an ``imageio`` plugin work. .. code:: yaml - module-name: 'imageio.core.imopen' anti-bloat: - replacements_plain: '`pip install imageio[{config.install_name}]` to install it': '`--include-module={config.module_name}` with Nuitka to include it' 'err_type = ImportError': 'err_type = RuntimeError' when: 'not deployment' And much more ------------- The deployment mode is relatively new and has constantly more features added, e.g. something for ``FileNotFoundError`` should be coming soon. Disabling All ------------- All these helpers can of course be disabled at once with ``--deployment`` but keep in mind that for debugging, you may want to re-enable it. You might want to use Nuitka Project options and an environment variable to make this conditional. Should you disable them all? We believe, disabling should only happen selectively, but with PyPI upgrades, your code changes, all of these issues can sneak back in. The space saving of deployment mode is currently negligible, so attempt to not do it, but review what exists, and if you know that it cannot affect you, or if it does, you will not need it. Some of the future ones, will clearly be geared at beginner level usage. Windows Virus scanners ====================== Binaries compiled on Windows with default settings of Nuitka and no further actions taken might be recognized by some AV vendors as malware. This is avoidable, but only in Nuitka commercial there is actual support and instructions for how to do it, seeing this as a typical commercial only need. https://nuitka.net/doc/commercial.html Linux Standalone ================ For Linux standalone it is pretty difficult to build a binary that works on other Linux versions. This is mainly because on Linux, much software is built specifically targeted to concrete DLLs. Things like glibc used, are then encoded into the binary built, and it will not run with an older glibc, just to give one critical example. The solution is to build on the oldest OS that you want to see supported. Picking that and setting it up can be tedious, so can be login, and keeping it secure, as it's something you put your source code on. To aid that, Nuitka commercial has container based builds, that you can use. This uses dedicated optimized Python builds, targets CentOS 7 and supports even newest Pythons and very old OSes that way using recent C compiler chains all turn key solution. The effort needs to be compensated to support Nuitka development for Linux, there you need to purchase it https://nuitka.net/doc/commercial.html but even a sponsor license will be cheaper than doing it yourself. Program crashes system (fork bombs) =================================== A fork bomb is a program that starts itself over and over. This can easily happen, since ``sys.executable`` for compiled programs is not a Python interpreter, and packages that try to do multiprocessing in a better way, often relaunch themselves through this, and Nuitka needs and does have handling for these with known packages. However, you may encounter a situation where the detection of this fails. See deployment option above that is needed to disable this protection. When this fork bomb happens easily all memory, all CPU of the system that is available to the user is being used, and even the most powerful build system will go down in flames sometimes needing a hard reboot. For fork bombs, we can use ``--experimental=debug-self-forking`` and see what it does, and we have a trick, that prevents fork bombs from having any actual success in their bombing. Put this at the start of your program. .. code:: python import os, sys if "NUITKA_LAUNCH_TOKEN" not in os.environ: sys.exit("Error, need launch token or else fork bomb suspected.") else: del os.environ["NUITKA_LAUNCH_TOKEN"] Actually Nuitka is trying to get ahold of them without the deployment option already, finding "-c" and "-m" options, but it may not be perfect or not work well with a package (anymore). Memory issues and compiler bugs =============================== In some cases, the C compilers will crash saying they cannot allocate memory or that some input was truncated, or similar error messages, clearly from it. These are example error messages, that are a sure sign of too low memory, there is no end to them. .. code:: # gcc fatal error: error writing to -: Invalid argument Killed signal terminated program # MSVC fatal error C1002: compiler is out of heap space in pass 2 fatal error C1001: Internal compiler error There are several options you can explore here. Ask Nuitka to use less memory ----------------------------- There is a dedicated option ``--low-memory`` which influences decisions of Nuitka, such that it avoids high usage of memory during compilation at the cost of increased compile time. Avoid 32 bit C compiler/assembler memory limits ----------------------------------------------- Do not use a 32 bit compiler, but a 64 bit one. If you are using Python with 32 bits on Windows, you most definitely ought to use MSVC as the C compiler, and not MinGW64. The MSVC is a cross-compiler, and can use more memory than gcc on that platform. If you are not on Windows, that is not an option, of course. Also, using the 64 bit Python will work. Use a minimal virtualenv ------------------------ When you compile from a living installation, that may well have many optional dependencies of your software installed. Some software will then have imports on these, and Nuitka will compile them as well. Not only may these be just the troublemakers, they also require more memory, so get rid of that. Of course, you do have to check that your program has all the needed dependencies before you attempt to compile, or else the compiled program will equally not run. Use LTO compilation or not -------------------------- With ``--lto=yes`` or ``--lto=no`` you can switch the C compilation to only produce bytecode, and not assembler code and machine code directly, but make a whole program optimization at the end. This will change the memory usage pretty dramatically, and if your error is coming from the assembler, using LTO will most definitely avoid that. Switch the C compiler to clang ------------------------------ People have reported that programs that fail to compile with gcc due to its bugs or memory usage work fine with clang on Linux. On Windows, this could still be an option, but it needs to be implemented first for the automatic downloaded gcc, that would contain it. Since MSVC is known to be more memory effective anyway, you should go there, and if you want to use Clang, there is support for the one contained in MSVC. Add a larger swap file to your embedded Linux --------------------------------------------- On systems with not enough RAM, you need to use swap space. Running out of it is possibly a cause, and adding more swap space, or one at all, might solve the issue, but beware that it will make things extremely slow when the compilers swap back and forth, so consider the next tip first or on top of it. Limit the amount of compilation jobs ------------------------------------ With the ``--jobs`` option of Nuitka, it will not start many C compiler instances at once, each competing for the scarce resource of RAM. By picking a value of one, only one C compiler instance will be running, and on an 8 core system, that reduces the amount of memory by factor 8, so that's a natural choice right there. Dynamic ``sys.path`` ==================== If your script modifies ``sys.path``, e.g. inserts directories with source code relative to it, Nuitka will not be able to see those. However, if you set the ``PYTHONPATH`` to the resulting value, it will be able to compile it and find the used modules from these paths as well. Manual Python File Loading ========================== A very frequent pattern with private code is that it scans plugin directories of some kind, and e.g. uses ``os.listdir``, then considers Python filenames, and then opens a file and does ``exec`` on them. This approach works for Python code, but for compiled code, you should use this much cleaner approach, that works for pure Python code and is a lot less vulnerable. .. code:: python # Using a package name, to locate the plugins. This is also a sane # way to organize them into a directory. scan_path = scan_package.__path__ for item in pkgutil.iter_modules(scan_path): importlib.import_module(scan_package.__name__ + "." + item.name) # You may want to do it recursively, but we don't do this here in # this example. If you'd like to, handle that in this kind of branch. if item.ispkg: ... Missing data files in standalone ================================ If your program fails to find data file, it can cause all kinds of different behavior, e.g. a package might complain it is not the right version because a ``VERSION`` file check defaulted to an unknown. The absence of icon files or help texts, may raise strange errors. Often the error paths for files not being present are even buggy and will reveal programming errors like unbound local variables. Please look carefully at these exceptions, keeping in mind that this can be the cause. If your program works without standalone, chances are data files might be the cause. The most common error indicating file absence is of course an uncaught ``FileNotFoundError`` with a filename. You should figure out what package is missing files and then use ``--include-package-data`` (preferably), or ``--include-data-dir``/``--include-data-files`` to include them. Missing DLLs/EXEs in standalone =============================== Nuitka has plugins that deal with copying DLLs. For NumPy, SciPy, Tkinter, etc. These need special treatment to be able to run on other systems. Manually copying them is not enough and will give strange errors. Sometimes newer version of packages, esp. NumPy can be unsupported. In this case, you will have to raise an issue, and use the older one. If you want to manually add a DLL or an EXE because it is your project only, you will have to use user Yaml files describing where they can be found. This is described in detail with examples in the `Nuitka Package Configuration `__ page. Dependency creep in standalone ============================== Some packages are a single import, but to Nuitka mean that more than a thousand packages (literally) are to be included. The prime example of Pandas, which does want to plug and use just about everything you can imagine. Multiple frameworks for syntax highlighting everything imaginable take time. Nuitka will have to learn effective caching to deal with this in the future. Presently, you will have to deal with huge compilation times for these. A major weapon in fighting dependency creep should be applied, namely the ``anti-bloat`` plugin, which offers interesting abilities, that can be put to use and block unneeded imports, giving an error for where they occur. Use it e.g. like this ``--noinclude-pytest-mode=nofollow --noinclude-setuptools-mode=nofollow`` and e.g. also ``--noinclude-custom-mode=setuptools:error`` to get the compiler to error out for a specific package. Make sure to check its help output. It can take for each module of your choice, e.g. forcing also that e.g. ``PyQt5`` is considered uninstalled for standalone mode. It's also driven by a configuration file, ``anti-bloat.yml`` that you can contribute to, removing typical bloat from packages. Please don't hesitate to enhance it and make PRs towards Nuitka with it. Standalone: Finding files ========================= The standard code that normally works, also works, you should refer to ``os.path.dirname(__file__)`` or use all the packages like ``pkgutil``, ``pkg_resources``, ``importlib.resources`` to locate data files near the standalone binary. .. important:: What you should **not** do, is use the current directory ``os.getcwd``, or assume that this is the script directory, e.g. with paths like ``data/``. If you did that, it was never good code. Links, to a program, launching from another directory, etc. will all fail in bad ways. Do not make assumptions about the directory your program is started from. In case you mean to refer to the location of the ``.dist`` folder for files that are to reside near the binary, there is ``__compiled__.containing_dir`` that also abstracts all differences with ``--macos-create-app-bundle`` and the ``.app`` folder a having more nested structure. .. code:: python # This will find a file *near* your app or dist folder try: open(os.path.join(__compiled__.containing_dir, "user-provided-file.txt")) except NameError: open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) Onefile: Finding files ====================== There is a difference between ``sys.argv[0]`` and ``__file__`` of the main module for the onefile mode, that is caused by using a bootstrap to a temporary location. The first one will be the original executable path, whereas the second one will be the temporary or permanent path the bootstrap executable unpacks to. Data files will be in the later location, your original environment files will be in the former location. Given 2 files, one which you expect to be near your executable, and one which you expect to be inside the onefile binary, access them like this. .. code:: python # This will find a file *near* your onefile.exe open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) # This will find a file *inside* your onefile.exe open(os.path.join(os.path.dirname(__file__), "user-provided-file.txt")) # This will find a file *near* your onefile binary and work for standalone too try: open(os.path.join(__compiled__.containing_dir, "user-provided-file.txt")) except NameError: open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) .. note:: When the program is launched from the executable, the original ``sys.argv[0]`` from the invocation command line will not be preserved, it will be made an absolute path. For advanced use cases where one needs access to the original ``sys.argv[0]``, it may be found at ``__compiled__.original_argv0``. The field will read back as ``None`` if the program is not launched from the onefile executable, thus not having gone through the onefile bootstrap stage; the original ``sys.argv[0]`` would be preserved as well in this case. .. code:: python # Suppose the onefile binary is placed at /opt/abc/bin/foo, and it was # symlinked to /usr/local/bin/bar, and invoked as `bar ...`: assert sys.argv[0] == "/usr/local/bin/bar" assert __compiled__.original_argv0 == "bar" # If the onefile tempdir is overridden and the program is invoked # directly from the unpacked location, sys.argv[0] would not be touched. # # Suppose the onefile tempdir is /home/xx/.cache/abc/0.1.2, and the # foo.bin executable inside is symlinked to /usr/local/bin/baz, and # invoked as `baz ...`: assert sys.argv[0] == "baz" assert __compiled__.original_argv0 is None Windows Programs without console give no errors =============================================== For debugging purposes, use the options ``--force-stdout-spec`` and ``--force-stderr-spec`` with paths as documented for ``--onefile-tempdir-spec`` above. These can be relative to the program or absolute, so you can see the outputs given. Also you can run the program on a terminal prompt like ``CMD.exe`` to see its outputs. Deep copying uncompiled functions ================================= Sometimes people use this kind of code, which for packages on PyPI, we deal with by doing source code patches on the fly. If this is in your own code, here is what you can do: .. code:: python def binder(func, name): result = types.FunctionType(func.__code__, func.__globals__, name=func.__name__, argdefs=func.__defaults__, closure=func.__closure__) result = functools.update_wrapper(result, func) result.__kwdefaults__ = func.__kwdefaults__ result.__name__ = name return result Compiled functions cannot be used to create uncompiled ones from, so the above code will not work. However, there is a dedicated ``clone`` method, that is specific to them, so use this instead. .. code:: python def binder(func, name): try: result = func.clone() except AttributeError: result = types.FunctionType(func.__code__, func.__globals__, name=func.__name__, argdefs=func.__defaults__, closure=func.__closure__) result = functools.update_wrapper(result, func) result.__kwdefaults__ = func.__kwdefaults__ result.__name__ = name return result Modules: Extension modules are not executable directly ====================================================== A package can be compiled with Nuitka, no problem, but when it comes to executing it, ``python -m compiled_module`` is not going to work and give the error ``No code object available for AssertsTest`` because the compiled module is not source code, and Python will not just load it. The closest would be ``python -c "import compile_module"`` and you might have to call the main function yourself. To support this, the CPython ``runpy`` and/or ``ExtensionFileLoader`` would need improving such that Nuitka could supply its compiled module object for Python to use. ****** Tips ****** Nuitka Options in the code ========================== One clean way of providing options to Nuitka, that you will always use for your program, is to put them into the main file you compile. There is even support for conditional options, and options using pre-defined variables, this is an example: .. code:: python # Compilation mode, support OS-specific options # nuitka-project-if: {OS} in ("Windows", "Linux", "Darwin", "FreeBSD"): # nuitka-project: --mode=app # nuitka-project-else: # nuitka-project: --mode=standalone # The PySide2 plugin covers qt-plugins # nuitka-project: --enable-plugin=pyside2 # nuitka-project: --include-qt-plugins=qml The comments must be at the start of lines, and indentation inside of them is to be used, to end a conditional block, much like in Python. There are currently no other keywords than the used ones demonstrated above. You can put arbitrary Python expressions there, and if you wanted to e.g. access a version information of a package, you could simply use ``__import__("module_name").__version__`` if that would be required to e.g. enable or disable certain Nuitka settings. The only thing Nuitka does that makes this not Python expressions, is expanding ``{variable}`` for a pre-defined set of variables: Table with supported variables: +------------------+--------------------------------+------------------------------------------+ | Variable | What this Expands to | Example | +==================+================================+==========================================+ | {OS} | Name of the OS used | Linux, Windows, Darwin, FreeBSD, OpenBSD | +------------------+--------------------------------+------------------------------------------+ | {Version} | Version of Nuitka | e.g. (1, 6, 0) | +------------------+--------------------------------+------------------------------------------+ | {Commercial} | Version of Nuitka Commercial | e.g. (2, 1, 0) | +------------------+--------------------------------+------------------------------------------+ | {Arch} | Architecture used | x86_64, arm64, etc. | +------------------+--------------------------------+------------------------------------------+ | {MAIN_DIRECTORY} | Directory of the compiled file | some_dir/maybe_relative | +------------------+--------------------------------+------------------------------------------+ | {Flavor} | Variant of Python | e.g. Debian Python, Anaconda Python | +------------------+--------------------------------+------------------------------------------+ The use of ``{MAIN_DIRECTORY}`` is recommended when you want to specify a filename relative to the main script, e.g. for use in data file options or user package configuration yaml files, .. code:: python # nuitka-project: --include-data-files={MAIN_DIRECTORY}/my_icon.png=my_icon.png # nuitka-project: --user-package-configuration-file={MAIN_DIRECTORY}/user.nuitka-package.config.yml Python command line flags ========================= For passing things like ``-O`` or ``-S`` to Python, to your compiled program, there is a command line option name ``--python-flag=`` which makes Nuitka emulate these options. The most important ones are supported, more can certainly be added. Caching compilation results =========================== The C compiler, when invoked with the same input files, will take a long time and much CPU to compile over and over. Make sure you are having ``ccache`` installed and configured when using gcc (even on Windows). It will make repeated compilations much faster, even if things are not yet perfect, i.e. changes to the program can cause many C files to change, requiring a new compilation instead of using the cached result. On Windows, with gcc, Nuitka supports using ``ccache.exe``, which it will offer to download from an official source and install it automatically. This is the recommended way of using it on Windows, as other versions may cause issues e.g. hanging. Nuitka will pick up ``ccache`` if it's found in system ``PATH``, and it will also be possible to provide if by setting ``NUITKA_CCACHE_BINARY`` to the full path of the binary, this is for use in CI systems where environments might be non-standard. For the MSVC compilers and ClangCL setups, using the ``clcache`` is automatic and included in Nuitka. On macOS and Intel, there is an automatic download of a ``ccache`` binary from our site, for arm64 arches, it's recommended to use this setup, which installs Homebrew and ccache in there. Nuitka picks that one up automatically if it on that kind of machine. You need and should not use Homebrew with Nuitka otherwise, it's not the best for standalone deployments, but we can take ``ccache`` from there. .. code:: bash export HOMEBREW_INSTALL_FROM_API=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" eval $(/opt/homebrew/bin/brew shellenv) brew install ccache Control where Caches live ========================= The storage for cache results of all kinds, downloads, cached compilation results from C and Nuitka, is done in a platform dependent directory as determined by the ``appdirs`` package. However, you can override it with setting the environment variable ``NUITKA_CACHE_DIR`` to a base directory. This is for use in environments where the home directory is not persisted, but other paths are. There is also per cache control of these caches, here is a table of environment variables that you can set before starting the compilation, to make Nuitka store some of these caches in an entirely separate space. +------------------+-----------------------------------+----------------------------------------+ | Cache name | Environment Variable | Data Put there | +==================+===================================+========================================+ | downloads | NUITKA_CACHE_DIR_DOWNLOADS | Downloads made, e.g. dependency walker | +------------------+-----------------------------------+----------------------------------------+ | ccache | NUITKA_CACHE_DIR_CCACHE | Object files created by gcc | +------------------+-----------------------------------+----------------------------------------+ | clcache | NUITKA_CACHE_DIR_CLCACHE | Object files created by MSVC | +------------------+-----------------------------------+----------------------------------------+ | bytecode | NUITKA_CACHE_DIR_BYTECODE | Bytecode of demoted modules | +------------------+-----------------------------------+----------------------------------------+ | dll-dependencies | NUITKA_CACHE_DIR_DLL_DEPENDENCIES | DLL dependencies | +------------------+-----------------------------------+----------------------------------------+ Runners ======= Avoid running the ``nuitka`` binary, doing ``python -m nuitka`` will make a 100% sure you are using what you think you are. Using the wrong Python will make it give you ``SyntaxError`` for good code or ``ImportError`` for installed modules. That is happening, when you run Nuitka with Python2 on Python3 code and vice versa. By explicitly calling the same Python interpreter binary, you avoid that issue entirely. Fastest C Compilers =================== The fastest binaries of ``pystone.exe`` on Windows with 64 bits Python proved to be significantly faster with MinGW64, roughly 20% better score. So it is recommended for use over MSVC. Using ``clang-cl.exe`` of Clang7 was faster than MSVC, but still significantly slower than MinGW64, and it will be harder to use, so it is not recommended. On Linux, for ``pystone.bin``, the binary produced by ``clang6`` was faster than ``gcc-6.3``, but not by a significant margin. Since gcc is more often already installed, that is recommended to use for now. Differences in C compilation times have not yet been examined. Unexpected Slowdowns ==================== Using the Python DLL, like standard CPython does, can lead to unexpected slowdowns, e.g. in uncompiled code that works with Unicode strings. This is because calling to the DLL rather than residing in the DLL causes overhead, and this even happens to the DLL with itself, being slower, than a Python all contained in one binary. So if feasible, aim at static linking, which is currently only possible with Anaconda Python on non-Windows, Debian Python2, self compiled Pythons (do not activate ``--enable-shared``, not needed), and installs created with ``pyenv``. .. note:: On Anaconda, you may need to execute ``conda install libpython-static`` Standalone executables and dependencies ======================================= The process of making standalone executables for Windows traditionally involves using an external dependency walker to copy necessary libraries along with the compiled executables to the distribution folder. There are plenty of ways to find that something is missing. Do not manually copy things into the folder, esp. not DLLs, as that's not going to work. Instead, make bug reports to get these handled by Nuitka properly. Windows errors with resources ============================= On Windows, the Windows Defender tool and the Windows Indexing Service both scan the freshly created binaries, while Nuitka wants to work with it, e.g. adding more resources, and then preventing operations randomly due to holding locks. Make sure to exclude your compilation stage from these services. Windows standalone program redistribution ========================================= Whether compiling with MingW or MSVC, the standalone programs have external dependencies to Visual C Runtime libraries. Nuitka tries to ship those dependent DLLs by copying them from your system. Beginning with Microsoft Windows 10, Microsoft ships ``ucrt.dll`` (Universal C Runtime libraries) which handles calls to ``api-ms-crt-*.dll``. With earlier Windows platforms (and wine/ReactOS), you should consider installing Visual C runtime libraries before executing a Nuitka standalone compiled program. Depending on the used C compiler, you'll need the following redist versions on the target machines. However, notice that compilation using the 14.3 based version is always recommended, working and best supported, unless you want to target Windows 7. +------------------+-------------+----------+ | Visual C version | Redist Year | CPython | +==================+=============+==========+ | 14.3 | 2022 | 3.11 | +------------------+-------------+----------+ | 14.2 | 2019 | 3.5-3.10 | +------------------+-------------+----------+ | 14.1 | 2017 | 3.5-3.8 | +------------------+-------------+----------+ | 14.0 | 2015 | 3.5-3.8 | +------------------+-------------+----------+ | 10.0 | 2010 | 3.4 | +------------------+-------------+----------+ | 9.0 | 2008 | 2.6, 2.7 | +------------------+-------------+----------+ When using MingGW64 as downloaded by Nuitka, you'll need the following redist versions: +----------------------------+-------------+---------------------+ | MingGW64 version | Redist Year | CPython | +============================+=============+=====================+ | WinLibs automatic download | 2015 | 2.6, 2.7, 3.4- 3.11 | +----------------------------+-------------+---------------------+ Once the corresponding runtime libraries are installed on the target system, you may remove all ``api-ms-crt-*.dll`` files from your Nuitka compiled dist folder. Detecting Nuitka at run time ============================ Nuitka does *not* ``sys.frozen`` unlike other tools because it usually triggers inferior code for no reason. For Nuitka, we have the module attribute ``__compiled__`` to test if a specific module was compiled, and the function attribute ``__compiled__`` to test if a specific function was compiled. Providing extra Options to Nuitka C compilation =============================================== Nuitka will apply values from the environment variables ``CCFLAGS``, ``LDFLAGS`` during the compilation on top of what it determines to be necessary. Beware, of course, that this is only useful if you know what you are doing, so should this pose issues, raise them only with perfect information. Producing a 32 bit binary on a 64 bit Windows system ==================================================== Nuitka will automatically target the architecture of the Python you are using. If this is 64 bit, it will create a 64 bit binary, if it is 32 bit, it will create a 32 bit binary. You have the option to select the bits when you download the Python. In the output of ``python -m nuitka --version`` there is a line for the architecture. It's ``Arch: x86_64`` for 64 bits, and just ``Arch: x86`` for 32 bits. The C compiler will be picked to match that more or less automatically. If you specify it explicitly, and it mismatches, you will get a warning about the mismatch and informed that your compiler choice was rejected. ******************** Compilation Report ******************** When you use ``--report=compilation-report.xml`` Nuitka will create an XML file with detailed information about the compilation and packaging process. This is growing in completeness with every release and exposes module usage attempts, timings of the compilation, plugin influences, data file paths, DLLs, and reasons why things are included or not. At this time, the report contains absolute paths in some places, with your private information. The goal is to make this blended out by default because we also want to become able to compare compilation reports from different setups, e.g. with updated packages, and see the changes to Nuitka. The report is, however, recommended for your bug reporting. Also, another form is available, where the report is free form and according to a Jinja2 template of yours, and one that is included in Nuitka. The same information as used to produce the XML file is accessible. However, right now, this is not yet documented, but we plan to add a table with the data. For a reader of the source code that is familiar with Jinja2, however, it will be easy to do it now already. If you have a template, you can use it like this ``--report-template=your_template.rst.j2:your_report.rst`` and of course, the usage of restructured text, is only an example. You can use Markdown, your own XML, or whatever you see fit. Nuitka will just expand the template with the compilation report data. Currently, the following reports are included in Nuitka. You just use the name as a filename, and Nuitka will pick that one instead. +---------------+--------------+--------------------------------------------------------+ | Report Name | Status | Purpose | +===============+==============+========================================================+ | LicenseReport | experimental | Distributions used in a compilation with license texts | +---------------+--------------+--------------------------------------------------------+ .. note:: The community can and should contribute more report types and help enhancing the existing ones for good looks. ************* Performance ************* This chapter gives an overview, of what to currently expect in terms of performance from Nuitka. It's a work in progress and is updated as we go. The current focus for performance measurements is Python 2.7, but 3.x is going to follow later. pystone results =============== The results are the top value from this kind of output, running pystone 1000 times and taking the minimal value. The idea is that the fastest run is most meaningful, and eliminates usage spikes. .. code:: bash echo "Uncompiled Python2" for i in {1..100}; do BENCH=1 python2 tests/benchmarks/pystone.py ; done | sort -rn | head -n 1 python2 -m nuitka --lto=yes --pgo-c tests/benchmarks/pystone.py echo "Compiled Python2" for i in {1..100}; do BENCH=1 ./pystone.bin ; done | sort -n | head -rn 1 PYTHON3=python3.10 # Using a 100 gives semi-reliable values already, 1000 for best accuracy. RUNS=1000 $PYTHON3 -m nuitka --lto=yes --pgo-c --static-libpython=yes tests/benchmarks/pystone3.py echo "Uncompiled $PYTHON3" for i in $(seq 1 $RUNS); do BENCH=1 $PYTHON3 tests/benchmarks/pystone3.py ; done | sort -rn | head -n 1 echo "Compiled $PYTHON3" for i in $(seq 1 $RUNS); do BENCH=1 ./pystone3.bin ; done | sort -rn | head -n 1 +-------------------+-------------------+----------------------+---------------------+ | Python | Uncompiled | Compiled LTO | Compiled PGO | +===================+===================+======================+=====================+ | Debian Python 2.7 | 137497.87 (1.000) | 460995.20 (3.353) | 503681.91 (3.663) | +-------------------+-------------------+----------------------+---------------------+ | Nuitka Python 2.7 | 144074.78 (1.048) | 479271.51 (3.486) | 511247.44 (3.718) | +-------------------+-------------------+----------------------+---------------------+ Report issues or bugs ===================== Should you encounter any issues, bugs, or ideas, please visit the `Nuitka bug tracker `__ and report them. Best practices for reporting bugs: - Please always include the following information in your report, for the underlying Python version. You can easily copy&paste this into your report. It does contain more information than you think. Do not write something manually. You may always add, of course, .. code:: bash python -m nuitka --version - Try to make your example minimal. That is, try to remove code that does not contribute to the issue as much as possible. Ideally, come up with a small reproducing program that illustrates the issue, using ``print`` with different results when the program runs compiled or native. - If the problem occurs spuriously (i.e. not each time), try to set the environment variable ``PYTHONHASHSEED`` to ``0``, disabling hash randomization. If that makes the problem go away, try increasing in steps of 1 to a hash seed value that makes it happen every time, include it in your report. - Do not include the created code in your report. Given proper input, it's redundant, and it's not likely that I will look at it without the ability to change the Python or Nuitka source and re-run it. - Do not send screenshots of text, that is bad and lazy. Instead, capture text outputs from the console. *************************** Unsupported functionality *************************** The ``co_code`` attribute of code objects ========================================= The code objects are empty for native compiled functions. There is no bytecode with Nuitka's compiled function objects, so there is no way to provide it. PDB === There is no tracing of compiled functions to attach a debugger to. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275202.0 Nuitka-2.7.16/Nuitka.egg-info/SOURCES.txt0000600000175100017520000023734015063223202023542 0ustar00nuitka-buildslavenuitka-buildslaveChangelog.rst Developer_Manual.rst LICENSE.txt MANIFEST.in README.rst pyproject.toml setup.py Nuitka.egg-info/PKG-INFO Nuitka.egg-info/SOURCES.txt Nuitka.egg-info/dependency_links.txt Nuitka.egg-info/entry_points.txt Nuitka.egg-info/not-zip-safe Nuitka.egg-info/requires.txt Nuitka.egg-info/top_level.txt bin/autoformat-nuitka-source bin/check-nuitka-with-pylint bin/compare_with_cpython bin/compare_with_xml bin/measure-construct-performance bin/nuitka bin/nuitka-run doc/nuitka-run.1 doc/nuitka.1 doc/Logo/Nuitka-Logo-Horizontal.svg doc/Logo/Nuitka-Logo-Symbol.svg doc/Logo/Nuitka-Logo-Vertical.svg doc/images/Nuitka-Logo-Horizontal.png doc/images/Nuitka-Logo-Symbol.png doc/images/Nuitka-Logo-Vertical.png lib/hints.py misc/nuitka-run.cmd misc/nuitka.cmd nuitka/Builtins.py nuitka/BytecodeCaching.py nuitka/Bytecodes.py nuitka/CacheCleanup.py nuitka/Constants.py nuitka/Errors.py nuitka/HardImportRegistry.py nuitka/MainControl.py nuitka/ModuleRegistry.py nuitka/OptionParsing.py nuitka/Options.py nuitka/OutputDirectories.py nuitka/PostProcessing.py nuitka/Progress.py nuitka/PythonFlavors.py nuitka/PythonOperators.py nuitka/PythonVersions.py nuitka/Serialization.py nuitka/SourceCodeReferences.py nuitka/Tracing.py nuitka/TreeXML.py nuitka/Variables.py nuitka/Version.py nuitka/__init__.py nuitka/__main__.py nuitka/__past__.py nuitka/build/Backend.scons nuitka/build/CCompilerVersion.scons nuitka/build/DataComposerInterface.py nuitka/build/Offsets.scons nuitka/build/Onefile.scons nuitka/build/SconsCaching.py nuitka/build/SconsCompilerSettings.py nuitka/build/SconsHacks.py nuitka/build/SconsInterface.py nuitka/build/SconsProgress.py nuitka/build/SconsSpawn.py nuitka/build/SconsUtils.py nuitka/build/__init__.py nuitka/build/include/nuitka/allocator.h nuitka/build/include/nuitka/builtins.h nuitka/build/include/nuitka/calling.h nuitka/build/include/nuitka/checkers.h nuitka/build/include/nuitka/checksum_tools.h nuitka/build/include/nuitka/compiled_asyncgen.h nuitka/build/include/nuitka/compiled_cell.h nuitka/build/include/nuitka/compiled_coroutine.h nuitka/build/include/nuitka/compiled_frame.h nuitka/build/include/nuitka/compiled_function.h nuitka/build/include/nuitka/compiled_generator.h nuitka/build/include/nuitka/compiled_method.h nuitka/build/include/nuitka/constants.h nuitka/build/include/nuitka/constants_blob.h nuitka/build/include/nuitka/debug_settings.h nuitka/build/include/nuitka/environment_variables.h nuitka/build/include/nuitka/environment_variables_system.h nuitka/build/include/nuitka/exception_groups.h nuitka/build/include/nuitka/exceptions.h nuitka/build/include/nuitka/filesystem_paths.h nuitka/build/include/nuitka/freelists.h nuitka/build/include/nuitka/hedley.h nuitka/build/include/nuitka/helpers.h nuitka/build/include/nuitka/importing.h nuitka/build/include/nuitka/incbin.h nuitka/build/include/nuitka/jit_sources.h nuitka/build/include/nuitka/prelude.h nuitka/build/include/nuitka/printing.h nuitka/build/include/nuitka/python_pgo.h nuitka/build/include/nuitka/safe_string_ops.h nuitka/build/include/nuitka/threading.h nuitka/build/include/nuitka/tracing.h nuitka/build/include/nuitka/type_aliases.h nuitka/build/include/nuitka/unfreezing.h nuitka/build/include/nuitka/helper/attributes.h nuitka/build/include/nuitka/helper/boolean.h nuitka/build/include/nuitka/helper/bytearrays.h nuitka/build/include/nuitka/helper/bytes.h nuitka/build/include/nuitka/helper/calling_generated.h nuitka/build/include/nuitka/helper/comparisons_dual_eq.h nuitka/build/include/nuitka/helper/comparisons_dual_ge.h nuitka/build/include/nuitka/helper/comparisons_dual_gt.h nuitka/build/include/nuitka/helper/comparisons_dual_le.h nuitka/build/include/nuitka/helper/comparisons_dual_lt.h nuitka/build/include/nuitka/helper/comparisons_dual_ne.h nuitka/build/include/nuitka/helper/comparisons_eq.h nuitka/build/include/nuitka/helper/comparisons_ge.h nuitka/build/include/nuitka/helper/comparisons_gt.h nuitka/build/include/nuitka/helper/comparisons_le.h nuitka/build/include/nuitka/helper/comparisons_lt.h nuitka/build/include/nuitka/helper/comparisons_ne.h nuitka/build/include/nuitka/helper/complex.h nuitka/build/include/nuitka/helper/dictionaries.h nuitka/build/include/nuitka/helper/floats.h nuitka/build/include/nuitka/helper/import_hard.h nuitka/build/include/nuitka/helper/indexes.h nuitka/build/include/nuitka/helper/ints.h nuitka/build/include/nuitka/helper/iterators.h nuitka/build/include/nuitka/helper/lists.h nuitka/build/include/nuitka/helper/lists_generated.h nuitka/build/include/nuitka/helper/mappings.h nuitka/build/include/nuitka/helper/operations.h nuitka/build/include/nuitka/helper/operations_binary_add.h nuitka/build/include/nuitka/helper/operations_binary_bitand.h nuitka/build/include/nuitka/helper/operations_binary_bitor.h nuitka/build/include/nuitka/helper/operations_binary_bitxor.h nuitka/build/include/nuitka/helper/operations_binary_divmod.h nuitka/build/include/nuitka/helper/operations_binary_dual_add.h nuitka/build/include/nuitka/helper/operations_binary_floordiv.h nuitka/build/include/nuitka/helper/operations_binary_lshift.h nuitka/build/include/nuitka/helper/operations_binary_matmult.h nuitka/build/include/nuitka/helper/operations_binary_mod.h nuitka/build/include/nuitka/helper/operations_binary_mult.h nuitka/build/include/nuitka/helper/operations_binary_olddiv.h nuitka/build/include/nuitka/helper/operations_binary_pow.h nuitka/build/include/nuitka/helper/operations_binary_rshift.h nuitka/build/include/nuitka/helper/operations_binary_sub.h nuitka/build/include/nuitka/helper/operations_binary_truediv.h nuitka/build/include/nuitka/helper/operations_builtin_types.h nuitka/build/include/nuitka/helper/operations_inplace_add.h nuitka/build/include/nuitka/helper/operations_inplace_bitand.h nuitka/build/include/nuitka/helper/operations_inplace_bitor.h nuitka/build/include/nuitka/helper/operations_inplace_bitxor.h nuitka/build/include/nuitka/helper/operations_inplace_floordiv.h nuitka/build/include/nuitka/helper/operations_inplace_lshift.h nuitka/build/include/nuitka/helper/operations_inplace_matmult.h nuitka/build/include/nuitka/helper/operations_inplace_mod.h nuitka/build/include/nuitka/helper/operations_inplace_mult.h nuitka/build/include/nuitka/helper/operations_inplace_olddiv.h nuitka/build/include/nuitka/helper/operations_inplace_pow.h nuitka/build/include/nuitka/helper/operations_inplace_rshift.h nuitka/build/include/nuitka/helper/operations_inplace_sub.h nuitka/build/include/nuitka/helper/operations_inplace_truediv.h nuitka/build/include/nuitka/helper/raising.h nuitka/build/include/nuitka/helper/rangeobjects.h nuitka/build/include/nuitka/helper/richcomparisons.h nuitka/build/include/nuitka/helper/sequences.h nuitka/build/include/nuitka/helper/sets.h nuitka/build/include/nuitka/helper/slices.h nuitka/build/include/nuitka/helper/strings.h nuitka/build/include/nuitka/helper/subscripts.h nuitka/build/include/nuitka/helper/tuples.h nuitka/build/inline_copy/appdirs/LICENSE.txt nuitka/build/inline_copy/appdirs/appdirs.py nuitka/build/inline_copy/atomicwrites/LICENSE nuitka/build/inline_copy/atomicwrites/atomicwrites.py nuitka/build/inline_copy/bin/scons.py nuitka/build/inline_copy/clcache/clcache/LICENSE nuitka/build/inline_copy/clcache/clcache/__init__.py nuitka/build/inline_copy/clcache/clcache/caching.py nuitka/build/inline_copy/colorama/LICENSE.txt nuitka/build/inline_copy/colorama/colorama/__init__.py nuitka/build/inline_copy/colorama/colorama/ansi.py nuitka/build/inline_copy/colorama/colorama/ansitowin32.py nuitka/build/inline_copy/colorama/colorama/initialise.py nuitka/build/inline_copy/colorama/colorama/win32.py nuitka/build/inline_copy/colorama/colorama/winterm.py nuitka/build/inline_copy/glob2/LICENSE nuitka/build/inline_copy/glob2/glob2/__init__.py nuitka/build/inline_copy/glob2/glob2/compat.py nuitka/build/inline_copy/glob2/glob2/fnmatch.py nuitka/build/inline_copy/glob2/glob2/impl.py nuitka/build/inline_copy/jinja2/LICENSE.rst nuitka/build/inline_copy/jinja2/README.rst nuitka/build/inline_copy/jinja2/jinja2/__init__.py nuitka/build/inline_copy/jinja2/jinja2/_compat.py nuitka/build/inline_copy/jinja2/jinja2/_identifier.py nuitka/build/inline_copy/jinja2/jinja2/bccache.py nuitka/build/inline_copy/jinja2/jinja2/compiler.py nuitka/build/inline_copy/jinja2/jinja2/constants.py nuitka/build/inline_copy/jinja2/jinja2/debug.py nuitka/build/inline_copy/jinja2/jinja2/defaults.py nuitka/build/inline_copy/jinja2/jinja2/environment.py nuitka/build/inline_copy/jinja2/jinja2/exceptions.py nuitka/build/inline_copy/jinja2/jinja2/ext.py nuitka/build/inline_copy/jinja2/jinja2/filters.py nuitka/build/inline_copy/jinja2/jinja2/idtracking.py nuitka/build/inline_copy/jinja2/jinja2/lexer.py nuitka/build/inline_copy/jinja2/jinja2/loaders.py nuitka/build/inline_copy/jinja2/jinja2/meta.py nuitka/build/inline_copy/jinja2/jinja2/nativetypes.py nuitka/build/inline_copy/jinja2/jinja2/nodes.py nuitka/build/inline_copy/jinja2/jinja2/optimizer.py nuitka/build/inline_copy/jinja2/jinja2/parser.py nuitka/build/inline_copy/jinja2/jinja2/runtime.py nuitka/build/inline_copy/jinja2/jinja2/sandbox.py nuitka/build/inline_copy/jinja2/jinja2/tests.py nuitka/build/inline_copy/jinja2/jinja2/utils.py nuitka/build/inline_copy/jinja2/jinja2/visitor.py nuitka/build/inline_copy/jinja2_35/LICENSE.rst nuitka/build/inline_copy/jinja2_35/README.rst nuitka/build/inline_copy/jinja2_35/jinja2/__init__.py nuitka/build/inline_copy/jinja2_35/jinja2/_compat.py nuitka/build/inline_copy/jinja2_35/jinja2/_identifier.py nuitka/build/inline_copy/jinja2_35/jinja2/bccache.py nuitka/build/inline_copy/jinja2_35/jinja2/compiler.py nuitka/build/inline_copy/jinja2_35/jinja2/constants.py nuitka/build/inline_copy/jinja2_35/jinja2/debug.py nuitka/build/inline_copy/jinja2_35/jinja2/defaults.py nuitka/build/inline_copy/jinja2_35/jinja2/environment.py nuitka/build/inline_copy/jinja2_35/jinja2/exceptions.py nuitka/build/inline_copy/jinja2_35/jinja2/ext.py nuitka/build/inline_copy/jinja2_35/jinja2/filters.py nuitka/build/inline_copy/jinja2_35/jinja2/idtracking.py nuitka/build/inline_copy/jinja2_35/jinja2/lexer.py nuitka/build/inline_copy/jinja2_35/jinja2/loaders.py nuitka/build/inline_copy/jinja2_35/jinja2/meta.py nuitka/build/inline_copy/jinja2_35/jinja2/nativetypes.py nuitka/build/inline_copy/jinja2_35/jinja2/nodes.py nuitka/build/inline_copy/jinja2_35/jinja2/optimizer.py nuitka/build/inline_copy/jinja2_35/jinja2/parser.py nuitka/build/inline_copy/jinja2_35/jinja2/runtime.py nuitka/build/inline_copy/jinja2_35/jinja2/sandbox.py nuitka/build/inline_copy/jinja2_35/jinja2/tests.py nuitka/build/inline_copy/jinja2_35/jinja2/utils.py nuitka/build/inline_copy/jinja2_35/jinja2/visitor.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Action.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Builder.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/CacheDir.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Conftest.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Debug.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Defaults.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Environment.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Errors.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Executor.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Job.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Memoize.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/PathList.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/SConf.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/SConsign.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Sig.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Subst.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Taskmaster.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Util.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Warnings.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/cpp.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/dblite.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/exitfuncs.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Node/Alias.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Node/FS.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Node/Python.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Node/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Options/BoolOption.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Options/EnumOption.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Options/ListOption.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Options/PackageOption.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Options/PathOption.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Options/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/aix.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/cygwin.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/darwin.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/hpux.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/irix.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/os2.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/posix.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/sunos.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Platform/win32.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Scanner/C.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Scanner/Dir.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Scanner/Prog.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Scanner/RC.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Scanner/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Script/Interactive.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Script/Main.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Script/SConsOptions.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Script/SConscript.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Script/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/386asm.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/BitKeeper.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/CVS.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/GettextCommon.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/Perforce.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/PharLapCommon.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/RCS.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/SCCS.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/Subversion.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/aixc++.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/aixcc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/aixf77.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/aixlink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/applelink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/ar.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/as.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/bcc32.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/c++.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/cc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/cyglink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/default.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/dmd.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/filesystem.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/g++.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/g77.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/gas.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/gcc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/gdc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/gettext.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/gfortran.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/gnulink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/hpc++.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/hpcc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/hplink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/icc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/icl.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/ilink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/ilink32.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/install.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/intelc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/lex.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/link.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/linkloc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/m4.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/masm.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/mingw.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/msgfmt.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/msginit.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/msgmerge.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/mslib.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/mslink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/mssdk.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/msvc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/msvs.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/mwcc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/mwld.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/nasm.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/rmic.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/rpcgen.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/sgiar.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/sgic++.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/sgicc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/sgilink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/sunar.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/sunc++.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/suncc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/sunlink.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/tar.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/textfile.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/tlib.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/wix.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/xgettext.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/zip.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/MSCommon/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/MSCommon/arch.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/MSCommon/common.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/MSCommon/netframework.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/MSCommon/sdk.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/MSCommon/vc.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/MSCommon/vs.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Tool/docbook/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Variables/BoolVariable.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Variables/EnumVariable.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Variables/ListVariable.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Variables/PackageVariable.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Variables/PathVariable.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/Variables/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/__init__.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/_scons_builtins.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/_scons_collections.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/_scons_dbm.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/_scons_hashlib.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/_scons_io.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/_scons_sets.py nuitka/build/inline_copy/lib/scons-2.3.2/SCons/compat/_scons_subprocess.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Action.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Builder.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/CacheDir.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Conftest.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Debug.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Defaults.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Environment.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Errors.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Executor.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Job.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Memoize.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/PathList.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/SConf.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/SConsign.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Subst.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Taskmaster.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Util.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Warnings.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/cpp.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/dblite.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/exitfuncs.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Node/Alias.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Node/FS.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Node/Python.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Node/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/aix.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/cygwin.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/darwin.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/hpux.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/irix.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/mingw.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/os2.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/posix.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/sunos.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/virtualenv.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Platform/win32.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Scanner/C.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Scanner/Dir.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Scanner/Prog.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Scanner/RC.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Scanner/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Script/Interactive.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Script/Main.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Script/SConsOptions.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Script/SConscript.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Script/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/386asm.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/GettextCommon.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/PharLapCommon.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/aixc++.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/aixcc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/aixcxx.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/aixlink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/applelink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/ar.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/as.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/bcc32.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/c++.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/cc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/clang.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/clangxx.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/cxx.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/cyglink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/default.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/filesystem.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/g++.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/gas.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/gcc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/gettext_tool.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/gnulink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/gxx.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/hpc++.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/hpcc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/hpcxx.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/hplink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/icc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/icl.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/ilink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/ilink32.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/install.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/intelc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/link.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/linkloc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/m4.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/masm.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/mingw.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/msgfmt.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/msginit.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/msgmerge.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/mslib.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/mslink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/mssdk.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/msvc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/msvs.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/mwcc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/mwld.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/nasm.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/rmic.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/rpcgen.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sgiar.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sgic++.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sgicc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sgicxx.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sgilink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sunar.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sunc++.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/suncc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/suncxx.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/sunlink.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/tar.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/textfile.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/tlib.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/wix.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/xgettext.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/zip.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/MSCommon/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/MSCommon/arch.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/MSCommon/common.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/MSCommon/netframework.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/MSCommon/sdk.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/MSCommon/vc.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/MSCommon/vs.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/clangCommon/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Tool/docbook/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Variables/BoolVariable.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Variables/EnumVariable.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Variables/ListVariable.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Variables/PackageVariable.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Variables/PathVariable.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/Variables/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/compat/__init__.py nuitka/build/inline_copy/lib/scons-3.1.2/SCons/compat/_scons_dbm.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Action.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Builder.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/CacheDir.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Conftest.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Debug.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Defaults.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Environment.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/EnvironmentValues.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Errors.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Executor.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Job.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Memoize.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/PathList.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/SConf.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/SConsign.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Subst.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Taskmaster.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Util.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Warnings.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/cpp.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/dblite.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/exitfuncs.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Node/Alias.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Node/FS.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Node/Python.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Node/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/aix.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/cygwin.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/darwin.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/hpux.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/irix.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/mingw.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/os2.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/posix.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/sunos.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/virtualenv.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Platform/win32.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Scanner/C.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Scanner/Dir.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Scanner/Prog.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Scanner/RC.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Scanner/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Script/Interactive.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Script/Main.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Script/SConsOptions.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Script/SConscript.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Script/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/386asm.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/GettextCommon.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/PharLapCommon.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/aixc++.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/aixcc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/aixcxx.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/aixlink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/applelink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/ar.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/as.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/asm.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/bcc32.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/c++.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/cc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/clang.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/clangxx.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/cxx.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/cyglink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/default.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/filesystem.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/g++.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/gas.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/gcc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/gettext_tool.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/gnulink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/gxx.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/hpc++.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/hpcc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/hpcxx.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/hplink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/icc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/icl.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/ilink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/ilink32.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/install.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/intelc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/link.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/linkloc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/m4.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/masm.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/mingw.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/msgfmt.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/msginit.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/msgmerge.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/mslib.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/mslink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/mssdk.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/msvc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/msvs.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/mwcc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/mwld.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/nasm.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/rmic.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/rpcgen.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sgiar.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sgic++.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sgicc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sgicxx.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sgilink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sunar.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sunc++.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/suncc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/suncxx.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/sunlink.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/tar.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/textfile.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/tlib.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/wix.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/xgettext.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/zip.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/MSCommon/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/MSCommon/arch.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/MSCommon/common.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/MSCommon/netframework.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/MSCommon/sdk.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/MSCommon/vc.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/MSCommon/vs.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/clangCommon/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/linkCommon/LoadableModule.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/linkCommon/SharedLibrary.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Tool/linkCommon/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Utilities/ConfigureCache.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Utilities/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Utilities/sconsign.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Variables/BoolVariable.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Variables/EnumVariable.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Variables/ListVariable.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Variables/PackageVariable.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Variables/PathVariable.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/Variables/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/compat/__init__.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/compat/_scons_dbm.py nuitka/build/inline_copy/lib/scons-4.3.0/SCons/compat/win32.py nuitka/build/inline_copy/markupsafe/LICENSE.rst nuitka/build/inline_copy/markupsafe/markupsafe/__init__.py nuitka/build/inline_copy/markupsafe/markupsafe/_compat.py nuitka/build/inline_copy/markupsafe/markupsafe/_constants.py nuitka/build/inline_copy/markupsafe/markupsafe/_native.py nuitka/build/inline_copy/pefile/LICENSE.txt nuitka/build/inline_copy/pefile/pefile.py nuitka/build/inline_copy/pefile/ordlookup/__init__.py nuitka/build/inline_copy/pefile/ordlookup/oleaut32.py nuitka/build/inline_copy/pefile/ordlookup/ws2_32.py nuitka/build/inline_copy/pkg_resources/pkg_resources/__init__.py nuitka/build/inline_copy/pkg_resources/pkg_resources/py31compat.py nuitka/build/inline_copy/python_hacl/LICENSE.txt nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_MD5.c nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_MD5.h nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_SHA1.c nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_SHA1.h nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_SHA2.c nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_SHA2.h nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_SHA3.c nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Hash_SHA3.h nuitka/build/inline_copy/python_hacl/hacl_312/Hacl_Streaming_Types.h nuitka/build/inline_copy/python_hacl/hacl_312/python_hacl_namespaces.h nuitka/build/inline_copy/python_hacl/hacl_312/include/krml/FStar_UInt128_Verified.h nuitka/build/inline_copy/python_hacl/hacl_312/include/krml/FStar_UInt_8_16_32_64.h nuitka/build/inline_copy/python_hacl/hacl_312/include/krml/fstar_uint128_struct_endianness.h nuitka/build/inline_copy/python_hacl/hacl_312/include/krml/lowstar_endianness.h nuitka/build/inline_copy/python_hacl/hacl_312/include/krml/types.h nuitka/build/inline_copy/python_hacl/hacl_312/include/krml/internal/target.h nuitka/build/inline_copy/python_hacl/hacl_312/internal/Hacl_Hash_MD5.h nuitka/build/inline_copy/python_hacl/hacl_312/internal/Hacl_Hash_SHA1.h nuitka/build/inline_copy/python_hacl/hacl_312/internal/Hacl_Hash_SHA2.h nuitka/build/inline_copy/python_hacl/hacl_312/internal/Hacl_Hash_SHA3.h nuitka/build/inline_copy/stubgen/astunparse.py nuitka/build/inline_copy/stubgen/six.py nuitka/build/inline_copy/stubgen/stubgen.py nuitka/build/inline_copy/tqdm/tqdm/__init__.py nuitka/build/inline_copy/tqdm/tqdm/_main.py nuitka/build/inline_copy/tqdm/tqdm/_monitor.py nuitka/build/inline_copy/tqdm/tqdm/_tqdm.py nuitka/build/inline_copy/tqdm/tqdm/_tqdm_notebook.py nuitka/build/inline_copy/tqdm/tqdm/_tqdm_pandas.py nuitka/build/inline_copy/tqdm/tqdm/_utils.py nuitka/build/inline_copy/tqdm/tqdm/auto.py nuitka/build/inline_copy/tqdm/tqdm/autonotebook.py nuitka/build/inline_copy/tqdm/tqdm/dask.py nuitka/build/inline_copy/tqdm/tqdm/notebook.py nuitka/build/inline_copy/tqdm/tqdm/std.py nuitka/build/inline_copy/tqdm/tqdm/tk.py nuitka/build/inline_copy/tqdm/tqdm/utils.py nuitka/build/inline_copy/tqdm/tqdm/version.py nuitka/build/inline_copy/yaml/LICENSE nuitka/build/inline_copy/yaml/yaml/__init__.py nuitka/build/inline_copy/yaml/yaml/composer.py nuitka/build/inline_copy/yaml/yaml/constructor.py nuitka/build/inline_copy/yaml/yaml/cyaml.py nuitka/build/inline_copy/yaml/yaml/dumper.py nuitka/build/inline_copy/yaml/yaml/emitter.py nuitka/build/inline_copy/yaml/yaml/error.py nuitka/build/inline_copy/yaml/yaml/events.py nuitka/build/inline_copy/yaml/yaml/loader.py nuitka/build/inline_copy/yaml/yaml/nodes.py nuitka/build/inline_copy/yaml/yaml/parser.py nuitka/build/inline_copy/yaml/yaml/reader.py nuitka/build/inline_copy/yaml/yaml/representer.py nuitka/build/inline_copy/yaml/yaml/resolver.py nuitka/build/inline_copy/yaml/yaml/scanner.py nuitka/build/inline_copy/yaml/yaml/serializer.py nuitka/build/inline_copy/yaml/yaml/tokens.py nuitka/build/inline_copy/yaml_27/LICENSE nuitka/build/inline_copy/yaml_27/yaml/__init__.py nuitka/build/inline_copy/yaml_27/yaml/composer.py nuitka/build/inline_copy/yaml_27/yaml/constructor.py nuitka/build/inline_copy/yaml_27/yaml/cyaml.py nuitka/build/inline_copy/yaml_27/yaml/dumper.py nuitka/build/inline_copy/yaml_27/yaml/emitter.py nuitka/build/inline_copy/yaml_27/yaml/error.py nuitka/build/inline_copy/yaml_27/yaml/events.py nuitka/build/inline_copy/yaml_27/yaml/loader.py nuitka/build/inline_copy/yaml_27/yaml/nodes.py nuitka/build/inline_copy/yaml_27/yaml/parser.py nuitka/build/inline_copy/yaml_27/yaml/reader.py nuitka/build/inline_copy/yaml_27/yaml/representer.py nuitka/build/inline_copy/yaml_27/yaml/resolver.py nuitka/build/inline_copy/yaml_27/yaml/scanner.py nuitka/build/inline_copy/yaml_27/yaml/serializer.py nuitka/build/inline_copy/yaml_27/yaml/tokens.py nuitka/build/inline_copy/yaml_35/LICENSE nuitka/build/inline_copy/yaml_35/yaml/__init__.py nuitka/build/inline_copy/yaml_35/yaml/composer.py nuitka/build/inline_copy/yaml_35/yaml/constructor.py nuitka/build/inline_copy/yaml_35/yaml/cyaml.py nuitka/build/inline_copy/yaml_35/yaml/dumper.py nuitka/build/inline_copy/yaml_35/yaml/emitter.py nuitka/build/inline_copy/yaml_35/yaml/error.py nuitka/build/inline_copy/yaml_35/yaml/events.py nuitka/build/inline_copy/yaml_35/yaml/loader.py nuitka/build/inline_copy/yaml_35/yaml/nodes.py nuitka/build/inline_copy/yaml_35/yaml/parser.py nuitka/build/inline_copy/yaml_35/yaml/reader.py nuitka/build/inline_copy/yaml_35/yaml/representer.py nuitka/build/inline_copy/yaml_35/yaml/resolver.py nuitka/build/inline_copy/yaml_35/yaml/scanner.py nuitka/build/inline_copy/yaml_35/yaml/serializer.py nuitka/build/inline_copy/yaml_35/yaml/tokens.py nuitka/build/inline_copy/zlib/LICENSE nuitka/build/inline_copy/zlib/crc32.c nuitka/build/inline_copy/zlib/crc32.h nuitka/build/inline_copy/zlib/zconf.h nuitka/build/inline_copy/zlib/zlib.h nuitka/build/inline_copy/zlib/zutil.h nuitka/build/inline_copy/zstd/LICENSE.txt nuitka/build/inline_copy/zstd/zstd.h nuitka/build/inline_copy/zstd/common/bitstream.h nuitka/build/inline_copy/zstd/common/compiler.h nuitka/build/inline_copy/zstd/common/cpu.h nuitka/build/inline_copy/zstd/common/debug.h nuitka/build/inline_copy/zstd/common/entropy_common.c nuitka/build/inline_copy/zstd/common/error_private.c nuitka/build/inline_copy/zstd/common/error_private.h nuitka/build/inline_copy/zstd/common/fse.h nuitka/build/inline_copy/zstd/common/fse_decompress.c nuitka/build/inline_copy/zstd/common/huf.h nuitka/build/inline_copy/zstd/common/mem.h nuitka/build/inline_copy/zstd/common/xxhash.c nuitka/build/inline_copy/zstd/common/xxhash.h nuitka/build/inline_copy/zstd/common/zstd_common.c nuitka/build/inline_copy/zstd/common/zstd_deps.h nuitka/build/inline_copy/zstd/common/zstd_errors.h nuitka/build/inline_copy/zstd/common/zstd_internal.h nuitka/build/inline_copy/zstd/decompress/huf_decompress.c nuitka/build/inline_copy/zstd/decompress/zstd_ddict.c nuitka/build/inline_copy/zstd/decompress/zstd_ddict.h nuitka/build/inline_copy/zstd/decompress/zstd_decompress.c nuitka/build/inline_copy/zstd/decompress/zstd_decompress_block.c nuitka/build/inline_copy/zstd/decompress/zstd_decompress_block.h nuitka/build/inline_copy/zstd/decompress/zstd_decompress_internal.h nuitka/build/static_src/CompiledAsyncgenType.c nuitka/build/static_src/CompiledCellType.c nuitka/build/static_src/CompiledCodeHelpers.c nuitka/build/static_src/CompiledCoroutineType.c nuitka/build/static_src/CompiledFrameType.c nuitka/build/static_src/CompiledFunctionType.c nuitka/build/static_src/CompiledGeneratorType.c nuitka/build/static_src/CompiledGeneratorTypeUncompiledIntegration.c nuitka/build/static_src/CompiledMethodType.c nuitka/build/static_src/GenerateHeadersMain.c nuitka/build/static_src/HelpersAllocator.c nuitka/build/static_src/HelpersAttributes.c nuitka/build/static_src/HelpersBuiltin.c nuitka/build/static_src/HelpersBuiltinTypeMethods.c nuitka/build/static_src/HelpersBytes.c nuitka/build/static_src/HelpersCalling.c nuitka/build/static_src/HelpersCallingGenerated.c nuitka/build/static_src/HelpersChecksumTools.c nuitka/build/static_src/HelpersClasses.c nuitka/build/static_src/HelpersComparisonDualEq.c nuitka/build/static_src/HelpersComparisonDualGe.c nuitka/build/static_src/HelpersComparisonDualGt.c nuitka/build/static_src/HelpersComparisonDualLe.c nuitka/build/static_src/HelpersComparisonDualLt.c nuitka/build/static_src/HelpersComparisonDualNe.c nuitka/build/static_src/HelpersComparisonEq.c nuitka/build/static_src/HelpersComparisonEqUtils.c nuitka/build/static_src/HelpersComparisonGe.c nuitka/build/static_src/HelpersComparisonGt.c nuitka/build/static_src/HelpersComparisonLe.c nuitka/build/static_src/HelpersComparisonLt.c nuitka/build/static_src/HelpersComparisonNe.c nuitka/build/static_src/HelpersConsole.c nuitka/build/static_src/HelpersConstantsBlob.c nuitka/build/static_src/HelpersDeepcopy.c nuitka/build/static_src/HelpersDictionaries.c nuitka/build/static_src/HelpersDictionariesGenerated.c nuitka/build/static_src/HelpersDumpBacktraces.c nuitka/build/static_src/HelpersEnvironmentVariables.c nuitka/build/static_src/HelpersEnvironmentVariablesSystem.c nuitka/build/static_src/HelpersExceptions.c nuitka/build/static_src/HelpersFiles.c nuitka/build/static_src/HelpersFilesystemPaths.c nuitka/build/static_src/HelpersFloats.c nuitka/build/static_src/HelpersHeapStorage.c nuitka/build/static_src/HelpersImport.c nuitka/build/static_src/HelpersImportHard.c nuitka/build/static_src/HelpersJitSources.c nuitka/build/static_src/HelpersLists.c nuitka/build/static_src/HelpersListsGenerated.c nuitka/build/static_src/HelpersMappings.c nuitka/build/static_src/HelpersMatching.c nuitka/build/static_src/HelpersOperationBinaryAdd.c nuitka/build/static_src/HelpersOperationBinaryAddUtils.c nuitka/build/static_src/HelpersOperationBinaryBitand.c nuitka/build/static_src/HelpersOperationBinaryBitor.c nuitka/build/static_src/HelpersOperationBinaryBitxor.c nuitka/build/static_src/HelpersOperationBinaryDivmod.c nuitka/build/static_src/HelpersOperationBinaryDivmodUtils.c nuitka/build/static_src/HelpersOperationBinaryDualAdd.c nuitka/build/static_src/HelpersOperationBinaryFloordiv.c nuitka/build/static_src/HelpersOperationBinaryInplaceAdd.c nuitka/build/static_src/HelpersOperationBinaryLshift.c nuitka/build/static_src/HelpersOperationBinaryMatmult.c nuitka/build/static_src/HelpersOperationBinaryMod.c nuitka/build/static_src/HelpersOperationBinaryMult.c nuitka/build/static_src/HelpersOperationBinaryMultUtils.c nuitka/build/static_src/HelpersOperationBinaryOlddiv.c nuitka/build/static_src/HelpersOperationBinaryPow.c nuitka/build/static_src/HelpersOperationBinaryPowUtils.c nuitka/build/static_src/HelpersOperationBinaryRshift.c nuitka/build/static_src/HelpersOperationBinarySub.c nuitka/build/static_src/HelpersOperationBinaryTruediv.c nuitka/build/static_src/HelpersOperationInplaceAdd.c nuitka/build/static_src/HelpersOperationInplaceAddUtils.c nuitka/build/static_src/HelpersOperationInplaceBitand.c nuitka/build/static_src/HelpersOperationInplaceBitor.c nuitka/build/static_src/HelpersOperationInplaceBitxor.c nuitka/build/static_src/HelpersOperationInplaceFloordiv.c nuitka/build/static_src/HelpersOperationInplaceLshift.c nuitka/build/static_src/HelpersOperationInplaceMatmult.c nuitka/build/static_src/HelpersOperationInplaceMod.c nuitka/build/static_src/HelpersOperationInplaceMult.c nuitka/build/static_src/HelpersOperationInplaceOlddiv.c nuitka/build/static_src/HelpersOperationInplacePow.c nuitka/build/static_src/HelpersOperationInplaceRshift.c nuitka/build/static_src/HelpersOperationInplaceSub.c nuitka/build/static_src/HelpersOperationInplaceTruediv.c nuitka/build/static_src/HelpersProfiling.c nuitka/build/static_src/HelpersPythonPgo.c nuitka/build/static_src/HelpersRaising.c nuitka/build/static_src/HelpersSafeStrings.c nuitka/build/static_src/HelpersSequences.c nuitka/build/static_src/HelpersSlices.c nuitka/build/static_src/HelpersStrings.c nuitka/build/static_src/HelpersTuples.c nuitka/build/static_src/HelpersTypes.c nuitka/build/static_src/InspectPatcher.c nuitka/build/static_src/MainProgram.c nuitka/build/static_src/MetaPathBasedLoader.c nuitka/build/static_src/MetaPathBasedLoaderImportlibMetadataDistribution.c nuitka/build/static_src/MetaPathBasedLoaderResourceReader.c nuitka/build/static_src/MetaPathBasedLoaderResourceReaderFiles.c nuitka/build/static_src/OnefileBootstrap.c nuitka/build/static_src/OnefileSplashScreen.cpp nuitka/code_generation/AsyncgenCodes.py nuitka/code_generation/AttributeCodes.py nuitka/code_generation/BinaryOperationHelperDefinitions.py nuitka/code_generation/BranchCodes.py nuitka/code_generation/BuiltinCodes.py nuitka/code_generation/CallCodes.py nuitka/code_generation/ClassCodes.py nuitka/code_generation/CodeGeneration.py nuitka/code_generation/CodeHelperSelection.py nuitka/code_generation/CodeHelpers.py nuitka/code_generation/CodeObjectCodes.py nuitka/code_generation/ComparisonCodes.py nuitka/code_generation/ComparisonHelperDefinitions.py nuitka/code_generation/ConditionalCodes.py nuitka/code_generation/ConstantCodes.py nuitka/code_generation/Contexts.py nuitka/code_generation/CoroutineCodes.py nuitka/code_generation/CtypesCodes.py nuitka/code_generation/DictCodes.py nuitka/code_generation/Emission.py nuitka/code_generation/ErrorCodes.py nuitka/code_generation/EvalCodes.py nuitka/code_generation/ExceptionCodes.py nuitka/code_generation/ExpressionCTypeSelectionHelpers.py nuitka/code_generation/ExpressionCodes.py nuitka/code_generation/FrameCodes.py nuitka/code_generation/FunctionCodes.py nuitka/code_generation/GeneratorCodes.py nuitka/code_generation/GlobalConstants.py nuitka/code_generation/GlobalsLocalsCodes.py nuitka/code_generation/IdCodes.py nuitka/code_generation/ImportCodes.py nuitka/code_generation/Indentation.py nuitka/code_generation/IndexCodes.py nuitka/code_generation/InjectCCodes.py nuitka/code_generation/IntegerCodes.py nuitka/code_generation/IteratorCodes.py nuitka/code_generation/JitCodes.py nuitka/code_generation/LabelCodes.py nuitka/code_generation/LineNumberCodes.py nuitka/code_generation/ListCodes.py nuitka/code_generation/LoaderCodes.py nuitka/code_generation/LocalsDictCodes.py nuitka/code_generation/LoopCodes.py nuitka/code_generation/MatchCodes.py nuitka/code_generation/ModuleCodes.py nuitka/code_generation/Namify.py nuitka/code_generation/NetworkxCodes.py nuitka/code_generation/OperationCodes.py nuitka/code_generation/PackageResourceCodes.py nuitka/code_generation/PrintCodes.py nuitka/code_generation/PythonAPICodes.py nuitka/code_generation/RaisingCodes.py nuitka/code_generation/Reports.py nuitka/code_generation/ReturnCodes.py nuitka/code_generation/SetCodes.py nuitka/code_generation/SliceCodes.py nuitka/code_generation/StringCodes.py nuitka/code_generation/SubscriptCodes.py nuitka/code_generation/TensorflowCodes.py nuitka/code_generation/TryCodes.py nuitka/code_generation/TupleCodes.py nuitka/code_generation/TypeAliasCodes.py nuitka/code_generation/VariableCodes.py nuitka/code_generation/VariableDeclarations.py nuitka/code_generation/YieldCodes.py nuitka/code_generation/__init__.py nuitka/code_generation/c_types/CTypeBases.py nuitka/code_generation/c_types/CTypeBooleans.py nuitka/code_generation/c_types/CTypeCFloats.py nuitka/code_generation/c_types/CTypeCLongs.py nuitka/code_generation/c_types/CTypeModuleDictVariables.py nuitka/code_generation/c_types/CTypeNuitkaBooleans.py nuitka/code_generation/c_types/CTypeNuitkaInts.py nuitka/code_generation/c_types/CTypeNuitkaVoids.py nuitka/code_generation/c_types/CTypePyObjectPointers.py nuitka/code_generation/c_types/CTypeVoids.py nuitka/code_generation/c_types/__init__.py nuitka/code_generation/templates/CodeTemplatesAsyncgens.py nuitka/code_generation/templates/CodeTemplatesConstants.py nuitka/code_generation/templates/CodeTemplatesCoroutines.py nuitka/code_generation/templates/CodeTemplatesExceptions.py nuitka/code_generation/templates/CodeTemplatesFrames.py nuitka/code_generation/templates/CodeTemplatesFunction.py nuitka/code_generation/templates/CodeTemplatesGeneratorFunction.py nuitka/code_generation/templates/CodeTemplatesIterators.py nuitka/code_generation/templates/CodeTemplatesLoader.py nuitka/code_generation/templates/CodeTemplatesModules.py nuitka/code_generation/templates/CodeTemplatesVariables.py nuitka/code_generation/templates/TemplateDebugWrapper.py nuitka/code_generation/templates/__init__.py nuitka/code_generation/templates_c/CodeTemplateCallsMethodPositional.c.j2 nuitka/code_generation/templates_c/CodeTemplateCallsMixed.c.j2 nuitka/code_generation/templates_c/CodeTemplateCallsPositional.c.j2 nuitka/code_generation/templates_c/CodeTemplateCallsPositionalMethodDescr.c.j2 nuitka/code_generation/templates_c/CodeTemplateMakeListHinted.c.j2 nuitka/code_generation/templates_c/CodeTemplateMakeListSmall.c.j2 nuitka/code_generation/templates_c/HelperBuiltinMethodOperation.c.j2 nuitka/code_generation/templates_c/HelperDictionaryCopy.c.j2 nuitka/code_generation/templates_c/HelperImportHard.c.j2 nuitka/code_generation/templates_c/HelperLongTools.c.j2 nuitka/code_generation/templates_c/HelperObjectTools.c.j2 nuitka/code_generation/templates_c/HelperOperationBinary.c.j2 nuitka/code_generation/templates_c/HelperOperationBinaryDual.c.j2 nuitka/code_generation/templates_c/HelperOperationComparison.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonBytes.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonDual.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonFloat.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonInt.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonList.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonLong.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonStr.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonTuple.c.j2 nuitka/code_generation/templates_c/HelperOperationComparisonUnicode.c.j2 nuitka/code_generation/templates_c/HelperOperationInplace.c.j2 nuitka/code_generation/templates_c/HelperSlotsBinary.c.j2 nuitka/code_generation/templates_c/HelperSlotsBytes.c.j2 nuitka/code_generation/templates_c/HelperSlotsCommon.c.j2 nuitka/code_generation/templates_c/HelperSlotsFloat.c.j2 nuitka/code_generation/templates_c/HelperSlotsInt.c.j2 nuitka/code_generation/templates_c/HelperSlotsList.c.j2 nuitka/code_generation/templates_c/HelperSlotsLong.c.j2 nuitka/code_generation/templates_c/HelperSlotsSet.c.j2 nuitka/code_generation/templates_c/HelperSlotsStr.c.j2 nuitka/code_generation/templates_c/HelperSlotsTuple.c.j2 nuitka/code_generation/templates_c/HelperSlotsUnicode.c.j2 nuitka/containers/Namedtuples.py nuitka/containers/OrderedDicts.py nuitka/containers/OrderedSets.py nuitka/containers/OrderedSetsFallback.py nuitka/containers/__init__.py nuitka/distutils/Build.py nuitka/distutils/DistutilCommands.py nuitka/distutils/__init__.py nuitka/finalizations/Finalization.py nuitka/finalizations/FinalizeMarkups.py nuitka/finalizations/__init__.py nuitka/freezer/DependsExe.py nuitka/freezer/DllDependenciesCommon.py nuitka/freezer/DllDependenciesMacOS.py nuitka/freezer/DllDependenciesPosix.py nuitka/freezer/DllDependenciesWin32.py nuitka/freezer/ImportDetection.py nuitka/freezer/IncludedDataFiles.py nuitka/freezer/IncludedEntryPoints.py nuitka/freezer/Onefile.py nuitka/freezer/Standalone.py nuitka/freezer/__init__.py nuitka/importing/IgnoreListing.py nuitka/importing/ImportCache.py nuitka/importing/ImportResolving.py nuitka/importing/Importing.py nuitka/importing/PreloadedPackages.py nuitka/importing/Recursion.py nuitka/importing/StandardLibrary.py nuitka/importing/__init__.py nuitka/nodes/AsyncgenNodes.py nuitka/nodes/AttributeLookupNodes.py nuitka/nodes/AttributeNodes.py nuitka/nodes/AttributeNodesGenerated.py nuitka/nodes/BuiltinAllNodes.py nuitka/nodes/BuiltinAnyNodes.py nuitka/nodes/BuiltinComplexNodes.py nuitka/nodes/BuiltinDecodingNodes.py nuitka/nodes/BuiltinDecoratorNodes.py nuitka/nodes/BuiltinDictNodes.py nuitka/nodes/BuiltinFormatNodes.py nuitka/nodes/BuiltinHashNodes.py nuitka/nodes/BuiltinInputNodes.py nuitka/nodes/BuiltinIntegerNodes.py nuitka/nodes/BuiltinIteratorNodes.py nuitka/nodes/BuiltinLenNodes.py nuitka/nodes/BuiltinNextNodes.py nuitka/nodes/BuiltinOpenNodes.py nuitka/nodes/BuiltinOperationNodeBasesGenerated.py nuitka/nodes/BuiltinRangeNodes.py nuitka/nodes/BuiltinRefNodes.py nuitka/nodes/BuiltinSumNodes.py nuitka/nodes/BuiltinTypeNodes.py nuitka/nodes/BuiltinVarsNodes.py nuitka/nodes/BytesNodes.py nuitka/nodes/CallNodes.py nuitka/nodes/Checkers.py nuitka/nodes/ChildrenHavingMixins.py nuitka/nodes/ClassNodes.py nuitka/nodes/CodeObjectSpecs.py nuitka/nodes/ComparisonNodes.py nuitka/nodes/ConditionalNodes.py nuitka/nodes/ConstantRefNodes.py nuitka/nodes/ContainerMakingNodes.py nuitka/nodes/ContainerOperationNodes.py nuitka/nodes/CoroutineNodes.py nuitka/nodes/CtypesNodes.py nuitka/nodes/DictionaryNodes.py nuitka/nodes/ExceptionNodes.py nuitka/nodes/ExecEvalNodes.py nuitka/nodes/ExpressionBases.py nuitka/nodes/ExpressionBasesGenerated.py nuitka/nodes/ExpressionShapeMixins.py nuitka/nodes/FrameNodes.py nuitka/nodes/FunctionAttributeNodes.py nuitka/nodes/FunctionNodes.py nuitka/nodes/FutureSpecs.py nuitka/nodes/GeneratorNodes.py nuitka/nodes/GlobalsLocalsNodes.py nuitka/nodes/HardImportNodesGenerated.py nuitka/nodes/ImportHardNodes.py nuitka/nodes/ImportNodes.py nuitka/nodes/IndicatorMixins.py nuitka/nodes/InjectCNodes.py nuitka/nodes/IterationHandles.py nuitka/nodes/KeyValuePairNodes.py nuitka/nodes/ListOperationNodes.py nuitka/nodes/LocalsDictNodes.py nuitka/nodes/LocalsScopes.py nuitka/nodes/LoopNodes.py nuitka/nodes/MatchNodes.py nuitka/nodes/ModuleAttributeNodes.py nuitka/nodes/ModuleNodes.py nuitka/nodes/NetworkxNodes.py nuitka/nodes/NodeBases.py nuitka/nodes/NodeMakingHelpers.py nuitka/nodes/NodeMetaClasses.py nuitka/nodes/OperatorNodes.py nuitka/nodes/OperatorNodesUnary.py nuitka/nodes/OsSysNodes.py nuitka/nodes/OutlineNodes.py nuitka/nodes/PackageMetadataNodes.py nuitka/nodes/PackageResourceNodes.py nuitka/nodes/PrintNodes.py nuitka/nodes/ReturnNodes.py nuitka/nodes/SideEffectNodes.py nuitka/nodes/SliceNodes.py nuitka/nodes/StatementBasesGenerated.py nuitka/nodes/StatementNodes.py nuitka/nodes/StrNodes.py nuitka/nodes/StringConcatenationNodes.py nuitka/nodes/SubscriptNodes.py nuitka/nodes/TensorflowNodes.py nuitka/nodes/TryNodes.py nuitka/nodes/TypeMatchNodes.py nuitka/nodes/TypeNodes.py nuitka/nodes/VariableAssignNodes.py nuitka/nodes/VariableDelNodes.py nuitka/nodes/VariableNameNodes.py nuitka/nodes/VariableRefNodes.py nuitka/nodes/VariableReleaseNodes.py nuitka/nodes/YieldNodes.py nuitka/nodes/__init__.py nuitka/nodes/shapes/BuiltinTypeShapes.py nuitka/nodes/shapes/ControlFlowDescriptions.py nuitka/nodes/shapes/IteratorShapes.py nuitka/nodes/shapes/ShapeMixins.py nuitka/nodes/shapes/StandardShapes.py nuitka/nodes/shapes/__init__.py nuitka/optimizations/BytecodeDemotion.py nuitka/optimizations/FunctionInlining.py nuitka/optimizations/Graphs.py nuitka/optimizations/Optimization.py nuitka/optimizations/OptimizeBuiltinCalls.py nuitka/optimizations/Tags.py nuitka/optimizations/TraceCollections.py nuitka/optimizations/ValueTraces.py nuitka/optimizations/__init__.py nuitka/pgo/PGO.py nuitka/pgo/__init__.py nuitka/plugins/PluginBase.py nuitka/plugins/Plugins.py nuitka/plugins/YamlPluginBase.py nuitka/plugins/__init__.py nuitka/plugins/standard/AntiBloatPlugin.py nuitka/plugins/standard/ConsiderPyLintAnnotationsPlugin.py nuitka/plugins/standard/DataFilesPlugin.py nuitka/plugins/standard/DelvewheelPlugin.py nuitka/plugins/standard/DillPlugin.py nuitka/plugins/standard/DllFilesPlugin.py nuitka/plugins/standard/EnumPlugin.py nuitka/plugins/standard/EventletPlugin.py nuitka/plugins/standard/GeventPlugin.py nuitka/plugins/standard/GiPlugin.py nuitka/plugins/standard/GlfwPlugin.py nuitka/plugins/standard/ImplicitImports.py nuitka/plugins/standard/KivyPlugin.py nuitka/plugins/standard/MatplotlibPlugin.py nuitka/plugins/standard/MultiprocessingPlugin.py nuitka/plugins/standard/NumpyPlugin.py nuitka/plugins/standard/OptionsNannyPlugin.py nuitka/plugins/standard/PbrPlugin.py nuitka/plugins/standard/PkgResourcesPlugin.py nuitka/plugins/standard/PlaywrightPlugin.py nuitka/plugins/standard/PmwPlugin.py nuitka/plugins/standard/PySidePyQtPlugin.py nuitka/plugins/standard/PywebViewPlugin.py nuitka/plugins/standard/SpacyPlugin.py nuitka/plugins/standard/TensorflowPlugin.py nuitka/plugins/standard/TkinterPlugin.py nuitka/plugins/standard/TorchPlugin.py nuitka/plugins/standard/TransformersPlugin.py nuitka/plugins/standard/TrioPlugin.py nuitka/plugins/standard/UpxPlugin.py nuitka/plugins/standard/__init__.py nuitka/plugins/standard/standard.nuitka-package.config.yml nuitka/plugins/standard/stdlib2.nuitka-package.config.yml nuitka/plugins/standard/stdlib3.nuitka-package.config.yml nuitka/plugins/standard/DillPlugin/DillPlugin.c nuitka/plugins/standard/DillPlugin/cloudpickle-postLoad.py nuitka/plugins/standard/DillPlugin/dill-postLoad.py nuitka/reports/CompilationReportReader.py nuitka/reports/LicenseReport.rst.j2 nuitka/reports/Reports.py nuitka/reports/__init__.py nuitka/specs/BuiltinBytesOperationSpecs.py nuitka/specs/BuiltinDictOperationSpecs.py nuitka/specs/BuiltinListOperationSpecs.py nuitka/specs/BuiltinParameterSpecs.py nuitka/specs/BuiltinStrOperationSpecs.py nuitka/specs/BuiltinTypeOperationSpecs.py nuitka/specs/BuiltinUnicodeOperationSpecs.py nuitka/specs/HardImportSpecs.py nuitka/specs/ParameterSpecs.py nuitka/specs/__init__.py nuitka/tools/Basics.py nuitka/tools/__init__.py nuitka/tools/commercial/__init__.py nuitka/tools/data_composer/DataComposer.py nuitka/tools/data_composer/__init__.py nuitka/tools/data_composer/__main__.py nuitka/tools/environments/CreateEnvironment.py nuitka/tools/environments/Virtualenv.py nuitka/tools/environments/__init__.py nuitka/tools/general/__init__.py nuitka/tools/general/dll_report/__init__.py nuitka/tools/general/dll_report/__main__.py nuitka/tools/general/find_module/FindModuleCode.py nuitka/tools/general/find_module/__init__.py nuitka/tools/general/generate_header/GenerateHeader.py nuitka/tools/general/generate_header/__init__.py nuitka/tools/onefile_compressor/OnefileCompressor.py nuitka/tools/onefile_compressor/__init__.py nuitka/tools/onefile_compressor/__main__.py nuitka/tools/podman/Podman.py nuitka/tools/podman/__init__.py nuitka/tools/podman/__main__.py nuitka/tools/profiler/__init__.py nuitka/tools/profiler/__main__.py nuitka/tools/scanning/DisplayDistributions.py nuitka/tools/scanning/DisplayPackageDLLs.py nuitka/tools/scanning/DisplayPackageData.py nuitka/tools/scanning/__init__.py nuitka/tools/specialize/CTypeDescriptions.py nuitka/tools/specialize/Common.py nuitka/tools/specialize/SpecializeC.py nuitka/tools/specialize/SpecializePython.py nuitka/tools/specialize/__init__.py nuitka/tools/testing/Common.py nuitka/tools/testing/Constructs.py nuitka/tools/testing/DocTests.py nuitka/tools/testing/OutputComparison.py nuitka/tools/testing/Pythons.py nuitka/tools/testing/RuntimeTracing.py nuitka/tools/testing/SearchModes.py nuitka/tools/testing/Valgrind.py nuitka/tools/testing/__init__.py nuitka/tools/testing/check_reference_counts/__init__.py nuitka/tools/testing/check_reference_counts/__main__.py nuitka/tools/testing/compare_with_cpython/__init__.py nuitka/tools/testing/compare_with_cpython/__main__.py nuitka/tools/testing/find_sxs_modules/__init__.py nuitka/tools/testing/find_sxs_modules/__main__.py nuitka/tools/testing/measure_construct_performance/__init__.py nuitka/tools/testing/measure_construct_performance/__main__.py nuitka/tools/testing/run_nuitka_tests/__init__.py nuitka/tools/testing/run_nuitka_tests/__main__.py nuitka/tools/watch/AutoStage.py nuitka/tools/watch/Common.py nuitka/tools/watch/Conda.py nuitka/tools/watch/GitHub.py nuitka/tools/watch/Pacman.py nuitka/tools/watch/Pipenv.py nuitka/tools/watch/__init__.py nuitka/tools/watch/__main__.py nuitka/tree/Building.py nuitka/tree/ComplexCallHelperFunctions.py nuitka/tree/Extractions.py nuitka/tree/FutureSpecState.py nuitka/tree/InternalModule.py nuitka/tree/Operations.py nuitka/tree/ReformulationAssertStatements.py nuitka/tree/ReformulationAssignmentStatements.py nuitka/tree/ReformulationBooleanExpressions.py nuitka/tree/ReformulationCallExpressions.py nuitka/tree/ReformulationClasses.py nuitka/tree/ReformulationClasses3.py nuitka/tree/ReformulationComparisonExpressions.py nuitka/tree/ReformulationContractionExpressions.py nuitka/tree/ReformulationDictionaryCreation.py nuitka/tree/ReformulationExecStatements.py nuitka/tree/ReformulationForLoopStatements.py nuitka/tree/ReformulationFunctionStatements.py nuitka/tree/ReformulationImportStatements.py nuitka/tree/ReformulationLambdaExpressions.py nuitka/tree/ReformulationMatchStatements.py nuitka/tree/ReformulationMultidist.py nuitka/tree/ReformulationNamespacePackages.py nuitka/tree/ReformulationPrintStatements.py nuitka/tree/ReformulationSequenceCreation.py nuitka/tree/ReformulationSubscriptExpressions.py nuitka/tree/ReformulationTryExceptStatements.py nuitka/tree/ReformulationTryFinallyStatements.py nuitka/tree/ReformulationWhileLoopStatements.py nuitka/tree/ReformulationWithStatements.py nuitka/tree/ReformulationYieldExpressions.py nuitka/tree/SourceHandling.py nuitka/tree/SyntaxErrors.py nuitka/tree/TreeHelpers.py nuitka/tree/VariableClosure.py nuitka/tree/__init__.py nuitka/utils/AppDirs.py nuitka/utils/CStrings.py nuitka/utils/CommandLineOptions.py nuitka/utils/Distributions.py nuitka/utils/Download.py nuitka/utils/Execution.py nuitka/utils/FileOperations.py nuitka/utils/Hashing.py nuitka/utils/Images.py nuitka/utils/Importing.py nuitka/utils/InlineCopies.py nuitka/utils/InstalledPythons.py nuitka/utils/InstanceCounters.py nuitka/utils/Jinja2.py nuitka/utils/Json.py nuitka/utils/MacOSApp.py nuitka/utils/MemoryUsage.py nuitka/utils/ModuleNames.py nuitka/utils/PackageResources.py nuitka/utils/ReExecute.py nuitka/utils/Rest.py nuitka/utils/SharedLibraries.py nuitka/utils/Shebang.py nuitka/utils/Signing.py nuitka/utils/SlotMetaClasses.py nuitka/utils/StaticLibraries.py nuitka/utils/ThreadedExecutor.py nuitka/utils/Timing.py nuitka/utils/Utils.py nuitka/utils/WindowsFileUsage.py nuitka/utils/WindowsResources.py nuitka/utils/Yaml.py nuitka/utils/__init__.py tests/run-tests tests/basics/AssertsTest.py tests/basics/AssignmentsTest.py tests/basics/AssignmentsTest32.py tests/basics/BranchingTest.py tests/basics/BuiltinOverload.py tests/basics/BuiltinSuperTest.py tests/basics/BuiltinsTest.py tests/basics/ClassMinimalTest.py tests/basics/ClassesTest.py tests/basics/ClassesTest32.py tests/basics/ClassesTest34.py tests/basics/ComparisonChainsTest.py tests/basics/ConstantsTest.py tests/basics/ConstantsTest27.py tests/basics/DecoratorsTest.py tests/basics/DefaultParametersTest.py tests/basics/DoubleDeletionsTest.py tests/basics/EmptyModuleTest.py tests/basics/ExceptionRaisingTest32.py tests/basics/ExceptionRaisingTest33.py tests/basics/ExceptionRaisingTest_2.py tests/basics/ExecEvalTest_2.py tests/basics/ExtremeClosureTest.py tests/basics/FunctionObjectsTest.py tests/basics/FunctionsTest.py tests/basics/FunctionsTest32.py tests/basics/FunctionsTest_2.py tests/basics/FutureTest32.py tests/basics/GeneratorExpressionsTest.py tests/basics/GeneratorExpressionsTest_37.py tests/basics/GlobalStatementTest.py tests/basics/HelloWorldTest_2.py tests/basics/ImportingTest.py tests/basics/InplaceOperationsTest.py tests/basics/InspectionTest.py tests/basics/InspectionTest_35.py tests/basics/InspectionTest_36.py tests/basics/LambdasTest.py tests/basics/LateClosureAssignmentTest.py tests/basics/ListContractionsTest.py tests/basics/LoopingTest.py tests/basics/MainProgramsTest.py tests/basics/ModuleAttributesTest.py tests/basics/OperatorsTest.py tests/basics/OrderChecksTest.py tests/basics/OrderChecksTest27.py tests/basics/OverflowFunctionsTest_2.py tests/basics/ParameterErrorsTest.py tests/basics/ParameterErrorsTest32.py tests/basics/PrintFutureTest.py tests/basics/PrintingTest_2.py tests/basics/RecursionTest.py tests/basics/ReferencingTest.py tests/basics/ReferencingTest27.py tests/basics/ReferencingTest33.py tests/basics/ReferencingTest35.py tests/basics/ReferencingTest36.py tests/basics/ReferencingTest_2.py tests/basics/SlotsTest.py tests/basics/ThreadedGeneratorsTest.py tests/basics/TrickAssignmentsTest32.py tests/basics/TrickAssignmentsTest35.py tests/basics/TrickAssignmentsTest_2.py tests/basics/TryContinueFinallyTest.py tests/basics/TryExceptContinueTest.py tests/basics/TryExceptFinallyTest.py tests/basics/TryExceptFramesTest.py tests/basics/TryReturnFinallyTest.py tests/basics/TryYieldFinallyTest.py tests/basics/UnicodeTest.py tests/basics/UnpackingTest35.py tests/basics/VarargsTest.py tests/basics/WithStatementsTest.py tests/basics/YieldFromTest33.py tests/basics/run_all.py tests/basics/run_xml.py tests/onefile/ExternalDataTest.py tests/onefile/HelloWorldTest.py tests/onefile/KeyboardInterruptTest.py tests/onefile/run_all.py tests/onefile/external-data/external-data.txt tests/optimizations/ArgumentTypes.py tests/optimizations/AttributesTest.py tests/optimizations/CallsTest.py tests/optimizations/ConditionsTest.py tests/optimizations/DecodingOperationsTest.py tests/optimizations/FormatStringsTest36.py tests/optimizations/HardImportsTest.py tests/optimizations/HardImportsTest_2.py tests/optimizations/Iterations.py tests/optimizations/LenTest.py tests/optimizations/MatchingTest310.py tests/optimizations/OperationsTest.py tests/optimizations/SubscriptsTest.py tests/optimizations/run_all.py tests/packages/run_all.py tests/packages/package_import_success_after_failure/PackageImportSuccessAfterFailureMain.py tests/packages/package_import_success_after_failure/variable_package/SomeModule.py tests/packages/package_import_success_after_failure/variable_package/__init__.py tests/packages/sub_package/kitty/__init__.py tests/packages/sub_package/kitty/bigkitty.py tests/packages/sub_package/kitty/smallkitty.py tests/packages/sub_package/kitty/speak/__init__.py tests/packages/sub_package/kitty/speak/hello.py tests/packages/sub_package/kitty/speak/miau.py tests/packages/sub_package/kitty/speak/purr.py tests/packages/top_level_attributes_3/some_package/__init__.py tests/packages/top_level_attributes_3/some_package/some_module.py tests/plugins/run_all.py tests/plugins/data_files/DataFilesMain.py tests/plugins/data_files/test_case.nuitka-package.config.yml tests/plugins/data_files/data_files_package/__init__.py tests/plugins/data_files/data_files_package/lala.txt tests/plugins/data_files/data_files_package/sub_dir/lulu.txt tests/plugins/dill_compat/DillCompatMain.py tests/plugins/parameters/ParametersMain.py tests/plugins/parameters/parameter-using-plugin.py tests/programs/run_all.py tests/programs/absolute_import/AbsoluteImportMain.py tests/programs/absolute_import/foobar/__init__.py tests/programs/absolute_import/foobar/foobar.py tests/programs/absolute_import/foobar/local.py tests/programs/absolute_import/foobar/util.py tests/programs/case_imports1/CasedImportingMain.py tests/programs/case_imports1/path1/Some_Module.py tests/programs/case_imports1/path1/Some_Package/__init__.py tests/programs/case_imports1/path2/some_module.py tests/programs/case_imports1/path2/some_package/__init__.py tests/programs/case_imports2/CasedImportingMain.py tests/programs/case_imports2/path1/some_module.py tests/programs/case_imports2/path1/some_package/__init__.py tests/programs/case_imports2/path2/Some_Module.py tests/programs/case_imports2/path2/Some_Package/__init__.py tests/programs/case_imports3/CasedImportingMain.py tests/programs/case_imports3/path1/Some_Module.py tests/programs/case_imports3/path1/Some_Package/__init__.py tests/programs/case_imports3/path2/Some_Module.py tests/programs/case_imports3/path2/Some_Package/__init__.py tests/programs/cyclic_imports/CyclicImportsMain.py tests/programs/cyclic_imports/cyclic_importing_package/Child1.py tests/programs/cyclic_imports/cyclic_importing_package/Child2.py tests/programs/cyclic_imports/cyclic_importing_package/__init__.py tests/programs/dash_import/DashImportMain.py tests/programs/dash_import/dash-module.py tests/programs/dash_import/plus+module.py tests/programs/dash_main/Dash-Main.py tests/programs/deep/DeepProgramMain.py tests/programs/deep/some_package/DeepBrother.py tests/programs/deep/some_package/DeepChild.py tests/programs/deep/some_package/__init__.py tests/programs/deep/some_package/deep_package/DeepDeepChild.py tests/programs/deep/some_package/deep_package/__init__.py tests/programs/dunderinit_imports/DunderInitImportsMain.py tests/programs/dunderinit_imports/package/SubModule.py tests/programs/dunderinit_imports/package/__init__.py tests/programs/import_variants/ImportVariationsMain.py tests/programs/import_variants/some_package/Child1.py tests/programs/import_variants/some_package/Child2.py tests/programs/import_variants/some_package/Child3.py tests/programs/import_variants/some_package/__init__.py tests/programs/main_raises/ErrorMain.py tests/programs/main_raises/ErrorRaising.py tests/programs/main_raises2/ErrorInFunctionMain.py tests/programs/main_raises2/ErrorRaising.py tests/programs/module_attributes/ModuleAttributesMain.py tests/programs/module_attributes/package_level1/Nearby1.py tests/programs/module_attributes/package_level1/__init__.py tests/programs/module_attributes/package_level1/package_level2/Nearby2.py tests/programs/module_attributes/package_level1/package_level2/__init__.py tests/programs/module_attributes/package_level1/package_level2/package_level3/Nearby3.py tests/programs/module_attributes/package_level1/package_level2/package_level3/__init__.py tests/programs/module_exits/ErrorExitingModule.py tests/programs/module_exits/Main.py tests/programs/module_object_replacing/ModuleObjectReplacingMain.py tests/programs/module_object_replacing/SelfReplacingModule.py tests/programs/multiprocessing_using/MultiprocessingUsingMain.py tests/programs/multiprocessing_using/foo/__init__.py tests/programs/multiprocessing_using/foo/__main__.py tests/programs/multiprocessing_using/foo/entry.py tests/programs/named_imports/NamedImportsMain.py tests/programs/named_imports/some_package/SomeModule.py tests/programs/named_imports/some_package/__init__.py tests/programs/named_imports/some_package/sub_package/SomeModule.py tests/programs/package_code/PackageInitCodeMain.py tests/programs/package_code/some_package/SomeModule.py tests/programs/package_code/some_package/__init__.py tests/programs/package_contains_main/PackageContainsMain.py tests/programs/package_contains_main/__init__.py tests/programs/package_contains_main/local.py tests/programs/package_init_import/PackageInitImportMain.py tests/programs/package_init_import/some_package/PackageLocal.py tests/programs/package_init_import/some_package/__init__.py tests/programs/package_init_issue/PackageInitIssueMain.py tests/programs/package_init_issue/some_package/__init__.py tests/programs/package_init_issue/some_package/child_package/SomeModule.py tests/programs/package_init_issue/some_package/child_package/__init__.py tests/programs/package_missing_init/PackageMissingInitMain.py tests/programs/package_missing_init/some_package/some_module.py tests/programs/package_missing_init/some_package/sub_package/some_sub_module.py tests/programs/package_module_collision/PackageAndModuleNamedSameMain.py tests/programs/package_module_collision/something.py tests/programs/package_module_collision/Something/__init__.py tests/programs/package_overload/Main.py tests/programs/package_overload/foo/__init__.py tests/programs/package_overload/foo/bar.py tests/programs/package_overload/foo/bar2.py tests/programs/package_prevents_submodule/PackagePreventsSubmoduleMain.py tests/programs/package_prevents_submodule/some_package/__init__.py tests/programs/package_prevents_submodule/some_package/some_module.py tests/programs/package_program/PackageAsMain/__init__.py tests/programs/package_program/PackageAsMain/__main__.py tests/programs/pkgutil_itermodules/PkgUtilIterModulesMain.py tests/programs/pkgutil_itermodules/some_package/__init__.py tests/programs/pkgutil_itermodules/some_package/sub_package1/SomeModuleC.py tests/programs/pkgutil_itermodules/some_package/sub_package1/SomeModuleD.py tests/programs/pkgutil_itermodules/some_package/sub_package1/__init__.py tests/programs/pkgutil_itermodules/some_package/sub_package2/SomeModuleA.py tests/programs/pkgutil_itermodules/some_package/sub_package2/SomeModuleB.py tests/programs/pkgutil_itermodules/some_package/sub_package2/__init__.py tests/programs/pkgutil_usage/PkgUtilUsageMain.py tests/programs/pkgutil_usage/package/DATA_FILE.txt tests/programs/pkgutil_usage/package/DATA_FILE2.txt tests/programs/pkgutil_usage/package/DATA_FILE3.txt tests/programs/pkgutil_usage/package/__init__.py tests/programs/plugin_import/PluginImportMain.py tests/programs/plugin_import/some_package/__init__.py tests/programs/plugin_import/some_package/some_module.py tests/programs/reimport_main_dynamic/ImportItselfDynamicMain.py tests/programs/reimport_main_static/ImportItselfStaticMain.py tests/programs/relative_import/RelativeImportMain.py tests/programs/relative_import/dircache.py tests/programs/resource_reader37/ResourceReaderMain.py tests/programs/resource_reader37/some_package/DATA_FILE.txt tests/programs/resource_reader37/some_package/__init__.py tests/programs/stdlib_overload/StdlibOverloadMain.py tests/programs/stdlib_overload/pyexpat.py tests/programs/stdlib_overload/some_package/__init__.py tests/programs/stdlib_overload/some_package/normal_importing.py tests/programs/stdlib_overload/some_package/pyexpat.py tests/programs/stdlib_overload/some_package/star_importing.py tests/programs/syntax_errors/IndentationErroring.py tests/programs/syntax_errors/SyntaxErroring.py tests/programs/syntax_errors/SyntaxErrorsMain.py tests/programs/unicode_bom/UnicodeBomMain.py tests/programs/unicode_bom/unicode_bom.py tests/programs/with space/Space Main.py tests/reflected/compile_itself.py tests/standalone/BrotliUsing.py tests/standalone/CtypesUsing.py tests/standalone/DateutilsUsing.py tests/standalone/FlaskUsing.py tests/standalone/GlfwUsing.py tests/standalone/GtkUsing.py tests/standalone/HexEncodingTest_2.py tests/standalone/IdnaUsing.py tests/standalone/LxmlUsing.py tests/standalone/MatplotlibUsing.py tests/standalone/MetadataPackagesUsing.py tests/standalone/NumpyUsing.py tests/standalone/OpenGLUsing.py tests/standalone/PandasUsing.py tests/standalone/PasslibUsing.py tests/standalone/PendulumUsing.py tests/standalone/PkgResourcesRequiresUsing.py tests/standalone/PmwUsing.py tests/standalone/PyQt5Plugins.py tests/standalone/PyQt5SSLSupport.py tests/standalone/PyQt5Using.py tests/standalone/PyQt6Plugins.py tests/standalone/PyQt6Using.py tests/standalone/PySide2Using.py tests/standalone/PySide6Plugins.py tests/standalone/PySide6Using.py tests/standalone/RsaUsing.py tests/standalone/SetuptoolsUsing_311.py tests/standalone/ShlibUsing.py tests/standalone/SocketUsing.py tests/standalone/TkInterUsing.py tests/standalone/Urllib3Using.py tests/standalone/Win32ComUsing.py tests/standalone/run_all.py tests/standalone/zip_importer/ZipImporterMain.py tests/syntax/AsyncgenReturn36.py tests/syntax/AwaitInModule36.py tests/syntax/BreakWithoutLoop.py tests/syntax/ClassReturn.py tests/syntax/ClosureDel_2.py tests/syntax/ContinueWithoutLoop.py tests/syntax/DuplicateArgument.py tests/syntax/ExecWithNesting_2.py tests/syntax/FutureBraces.py tests/syntax/FutureUnknown.py tests/syntax/GeneratorExpressions38.py tests/syntax/GeneratorReturn_2.py tests/syntax/GlobalForParameter.py tests/syntax/Importing32.py tests/syntax/IndentationError.py tests/syntax/LateFutureImport.py tests/syntax/MisplacedFutureImport.py tests/syntax/ModuleReturn.py tests/syntax/NonAsciiWithoutEncoding_2.py tests/syntax/NonlocalForParameter32.py tests/syntax/NonlocalNotFound32.py tests/syntax/StarImportExtra.py tests/syntax/SyntaxError.py tests/syntax/TryExceptAllNotLast.py tests/syntax/TryFinallyContinue_37.py tests/syntax/UnpackNoTuple.py tests/syntax/UnpackTwoStars32.py tests/syntax/YieldFromInModule.py tests/syntax/YieldInAsync35.py tests/syntax/YieldInGenexp38.py tests/syntax/YieldInModule.py tests/syntax/run_all.py././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275202.0 Nuitka-2.7.16/Nuitka.egg-info/dependency_links.txt0000600000175100017520000000000115063223202025713 0ustar00nuitka-buildslavenuitka-buildslave ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275202.0 Nuitka-2.7.16/Nuitka.egg-info/entry_points.txt0000600000175100017520000000060715063223202025146 0ustar00nuitka-buildslavenuitka-buildslave[console_scripts] nuitka = nuitka.__main__:main nuitka-run = nuitka.__main__:main [distutils.commands] bdist_nuitka = nuitka.distutils.DistutilCommands:bdist_nuitka build_nuitka = nuitka.distutils.DistutilCommands:build install_nuitka = nuitka.distutils.DistutilCommands:install [distutils.setup_keywords] build_with_nuitka = nuitka.distutils.DistutilCommands:setupNuitkaDistutilsCommands ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275202.0 Nuitka-2.7.16/Nuitka.egg-info/not-zip-safe0000600000175100017520000000000115063223202024073 0ustar00nuitka-buildslavenuitka-buildslave ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275202.0 Nuitka-2.7.16/Nuitka.egg-info/top_level.txt0000600000175100017520000000000715063223202024374 0ustar00nuitka-buildslavenuitka-buildslavenuitka ././@PaxHeader0000000000000000000000000000003300000000000010211 xustar0027 mtime=1758275202.512262 Nuitka-2.7.16/PKG-INFO0000600000175100017520000024473015063223203020030 0ustar00nuitka-buildslavenuitka-buildslaveMetadata-Version: 2.1 Name: Nuitka Version: 2.7.16 Summary: Python compiler with full language support and CPython compatibility Home-page: https://nuitka.net Author: Kay Hayen Author-email: Kay.Hayen@gmail.com License: Apache License, Version 2.0 Project-URL: Commercial, https://nuitka.net/doc/commercial.html Project-URL: Support, https://nuitka.net/pages/support.html Project-URL: Documentation, https://nuitka.net/doc/user-manual.html Project-URL: Donations, https://nuitka.net/pages/donations.html Project-URL: Mastodon, https://fosstodon.org/@kayhayen Project-URL: Twitter, https://twitter.com/KayHayen Project-URL: Source, https://github.com/Nuitka/Nuitka Keywords: compiler,python,nuitka Classifier: Development Status :: 5 - Production/Stable Classifier: Intended Audience :: Developers Classifier: Intended Audience :: Science/Research Classifier: Topic :: Software Development :: Compilers Classifier: Topic :: Software Development :: Build Tools Classifier: Topic :: Software Development :: Quality Assurance Classifier: Topic :: System :: Software Distribution Classifier: Programming Language :: Python :: 3.13 Classifier: Programming Language :: Python :: 3.12 Classifier: Programming Language :: Python :: 3.11 Classifier: Programming Language :: Python :: 3.10 Classifier: Programming Language :: Python :: 3.9 Classifier: Programming Language :: Python :: 3.8 Classifier: Programming Language :: Python :: 3.7 Classifier: Programming Language :: Python :: 3.6 Classifier: Programming Language :: Python :: 3.5 Classifier: Programming Language :: Python :: 3.4 Classifier: Programming Language :: Python :: 2.7 Classifier: Programming Language :: Python :: 2.6 Classifier: Programming Language :: Python :: Implementation :: CPython Classifier: Programming Language :: C Classifier: Operating System :: POSIX :: Linux Classifier: Operating System :: POSIX :: BSD :: FreeBSD Classifier: Operating System :: POSIX :: BSD :: NetBSD Classifier: Operating System :: POSIX :: BSD :: OpenBSD Classifier: Operating System :: Microsoft :: Windows Classifier: Operating System :: MacOS Classifier: Operating System :: Android Classifier: License :: OSI Approved :: Apache Software License Description-Content-Type: text/x-rst Provides-Extra: build-wheel License-File: LICENSE.txt .. image:: https://img.shields.io/pypi/pyversions/Nuitka.svg :target: https://pypi.org/project/Nuitka .. image:: https://badge.fury.io/py/Nuitka.svg :target: https://pypi.org/project/Nuitka .. image:: https://img.shields.io/badge/Contributor%20Covenant-v1.4%20adopted-ff69b4.svg :target: CODE_OF_CONDUCT.md #################### Nuitka User Manual #################### This document is the recommended first read when you start using **Nuitka**. On this page, you will learn more about **Nuitka** fundamentals, such as license type, use cases, requirements, and credits. .. contents:: Table of Contents :depth: 1 :local: :class: page-toc Nuitka is **the** Python compiler. It is written in Python. It is a seamless replacement or extension to the Python interpreter and compiles **every** construct that Python 2 (2.6, 2.7) and Python 3 (3.4 - 3.13) have, when itself run with that Python version. It then executes uncompiled code and compiled code together in an extremely compatible manner. You can use all Python library modules and all extension modules freely. Nuitka translates the Python modules into a C level program that then uses ``libpython`` and static C files of its own to execute in the same way as CPython does. All optimization is aimed at avoiding overhead, where it's unnecessary. None is aimed at removing compatibility, although slight improvements will occasionally be done, where not every bug of standard Python is emulated, e.g. more complete error messages are given, but there is a full compatibility mode to disable even that. ************** Requirements ************** To ensure smooth operation of **Nuitka**, make sure to follow system requirements, that include the following components: :depth: 1 :local: C Compiler ========== You need a C compiler with support for C11 or alternatively a C++ compiler for C++03 [#]_. Currently, this means, you need to use one of these compilers: - The MinGW64 C11 compiler, on Windows, must be based on gcc 11.2 or higher. It will be *automatically* downloaded if no usable C compiler is found, which is the recommended way of installing it, as Nuitka will also upgrade it for you. - Visual Studio 2022 or higher on Windows [#]_. English language pack for best results (Nuitka filters away garbage outputs, but only for English language). It will be used by default if installed. - On all other platforms, the ``gcc`` compiler of at least version 5.1, and below that the ``g++`` compiler of at least version 4.4 as an alternative. - The ``clang`` compiler on macOS X and most FreeBSD architectures. - On Windows, the ``clang-cl`` compiler on Windows can be used if provided by the Visual Studio installer. .. [#] Support for this C11 is given with gcc 5.x or higher or any clang version. The older MSVC compilers don't do it yet. But as a workaround, with Python 3.10 or older, the C++03 language standard is significantly overlapping with C11, it is then used instead. .. [#] Download for free from https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx (the community editions work just fine). The latest version is recommended, but not required. On the other hand, there is no need to except to support pre-Windows 10 versions, and they might work for you, but support of these configurations is only available to commercial users. Python ====== **Python 2** (2.6, 2.7) and **Python 3** (3.4 — 3.13) are supported. If at any moment, there is a stable Python release that is not in this list, rest assured it is being worked on and will be added. .. important:: For Python 3.4 and *only* that version, we need other Python version as a *compile time* dependency. Nuitka itself is fully compatible with all listed versions, but Scons as an internally used tool is not. For these versions, you *need* a Python2 or Python 3.5 or higher installed as well, but only during the compile time. That is for use with Scons (which orchestrates the C compilation), which does not support the same Python versions as Nuitka. In addition, on Windows, Python2 cannot be used because ``clcache`` does not work with it, there a Python 3.5 or higher needs to be installed. Nuitka finds these needed Python versions (e.g. on Windows via registry) and you shouldn't notice it as long as they are installed. Increasingly, other functionality is available when another Python has a certain package installed. For example, onefile compression will work for a Python 2.x when another Python is found that has the ``zstandard`` package installed. .. admonition:: Moving binaries to other machines The created binaries can be made executable independent of the Python installation, with ``--standalone`` and ``--onefile`` options. .. admonition:: Binary filename suffix The created binaries have an ``.exe`` suffix on Windows. On other platforms they have no suffix for standalone mode, or ``.bin`` suffix, that you are free to remove or change, or specify with the ``-o`` option. The suffix for acceleration mode is added just to be sure that the original script name and the binary name do not ever collide, so we can safely overwrite the binary without destroying the original source file. .. admonition:: It **has to** be CPython, Anaconda Python, or Homebrew You need the standard Python implementation, called "CPython", to execute Nuitka because it is closely tied to implementation details of it. .. admonition:: It **cannot be** from the Windows app store It is known that Windows app store Python definitely does not work, it's checked against. .. admonition:: It **cannot be** pyenv on macOS It is known that macOS "pyenv" does **not** work. Use Homebrew instead for self compiled Python installations. But note that standalone mode will be worse on these platforms and not be as backward compatible with older macOS versions. Operating System ================ Supported Operating Systems: Linux, FreeBSD, NetBSD, macOS, and Windows (32 bits/64 bits/ARM). Others will work as well. The portability is expected to be generally good, but the e.g. Nuitka's internal Scons usage may have to be adapted or need flags passed. Make sure to match Python and C compiler architecture, or else you will get cryptic error messages. Architecture ============ Supported Architectures are x86, x86_64 (amd64), and arm, likely many, many more. Other architectures are expected to also work, out of the box, as Nuitka is generally not using any hardware specifics. These are just the ones tested and known to be good. Feedback is welcome. Generally, the architectures that Debian supports can be considered good and tested, too. ******* Usage ******* Command Line ============ The recommended way of executing Nuitka is `` -m nuitka`` to be absolutely certain which Python interpreter you are using, so it is easier to match with what Nuitka has. The next best way of executing Nuitka bare that is from a source checkout or archive, with no environment variable changes, most noteworthy, you do not have to mess with ``PYTHONPATH`` at all for Nuitka. You just execute the ``nuitka`` and ``nuitka-run`` scripts directly without any changes to the environment. You may want to add the ``bin`` directory to your ``PATH`` for your convenience, but that step is optional. Moreover, if you want to execute with the right interpreter, in that case, be sure to execute `` bin/nuitka`` and be good. .. admonition:: Pick the right Interpreter If you encounter a ``SyntaxError`` you absolutely most certainly have picked the wrong interpreter for the program you are compiling. Nuitka has a ``--help`` option to output what it can do: .. code:: bash nuitka --help The ``nuitka-run`` command is the same as ``nuitka``, but with a different default. It tries to compile *and* directly execute a Python script: .. code:: bash nuitka-run --help This option that is different is ``--run``, and passing on arguments after the first non-option to the created binary, so it is somewhat more similar to what plain ``python`` will do. Installation ============ For most systems, there will be packages on the `download page `__ of Nuitka. But you can also install it from source code as described above, but also like any other Python program it can be installed via the normal ``python setup.py install`` routine. Notice for integration with GitHub workflows there is this `Nuitka-Action `__ that you should use that makes it really easy to integrate. You ought to start with a local compilation though, but this will be easiest for cross platform compilation with Nuitka. License ======= Nuitka is licensed under the Apache License, Version 2.0; you may not use it except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ************************************* Tutorial Setup and build on Windows ************************************* This is basic steps if you have nothing installed, of course if you have any of the parts, just skip it. Setup ===== Install Python -------------- - Download and install Python from https://www.python.org/downloads/windows - Select one of ``Windows x86-64 web-based installer`` (64 bits Python, recommended) or ``x86 executable`` (32 bits Python) installer. - Verify it's working using command ``python --version``. Install Nuitka -------------- - ``python -m pip install nuitka`` - Verify using command ``python -m nuitka --version`` Write some code and test ======================== Create a folder for the Python code ----------------------------------- - ``mkdir`` HelloWorld - make a python file named **hello.py** .. code:: python def talk(message): return "Talk " + message def main(): print(talk("Hello World")) if __name__ == "__main__": main() Test your program ----------------- Do as you normally would. Running Nuitka on code that works incorrectly is not easier to debug. .. code:: bash python hello.py ---- Build it using -------------- .. code:: bash python -m nuitka hello.py .. note:: This will prompt you to download a C caching tool (to speed up repeated compilation of generated C code) and a MinGW64 based C compiler, unless you have a suitable MSVC installed. Say ``yes`` to both those questions. Run it ------ Execute the ``hello.exe`` created near ``hello.py``. Distribute ---------- To distribute, build with ``--standalone`` option, which will not output a single executable, but a whole folder. Copy the resulting ``hello.dist`` folder to the other machine and run it. You may also try ``--onefile`` which does create a single file, but make sure that the mere standalone is working, before turning to it, as it will make the debugging only harder, e.g. in case of missing data files. *********** Use Cases *********** Use Case 1 — Program compilation with all modules embedded ============================================================ If you want to compile a whole program recursively, and not only the single file that is the main program, do it like this: .. code:: bash python -m nuitka --follow-imports program.py .. note:: There are more fine-grained controls than ``--follow-imports`` available. Consider the output of ``nuitka --help``. Including fewer modules into the compilation, but instead using normal Python for it, will make it faster to compile. In case you have a source directory with dynamically loaded files, i.e. one which cannot be found by recursing after normal import statements via the ``PYTHONPATH`` (which would be the recommended way), you can always require that a given directory shall also be included in the executable: .. code:: bash python -m nuitka --follow-imports --include-plugin-directory=plugin_dir program.py .. note:: If you don't do any dynamic imports, simply setting your ``PYTHONPATH`` at compilation time is what you should do. Use ``--include-plugin-directory`` only if you make ``__import__()`` calls that Nuitka cannot predict, and that come from a directory, for everything from your Python installation, use ``--include-module`` or ``--include-package``. .. note:: The resulting filename will be ``program.exe`` on Windows, ``program.bin`` on other platforms, but ``--output-filename`` allows changing that. .. note:: The resulting binary still depends on CPython and used C extension modules being installed. If you want to be able to copy it to another machine, use ``--standalone`` and copy the created ``program.dist`` directory and execute the ``program.exe`` (Windows) or ``program`` (other platforms) put inside. Use Case 2 — Extension Module compilation =========================================== If you want to compile a single extension module, all you have to do is this: .. code:: bash python -m nuitka --mode=module some_module.py The resulting file ``some_module.so`` can then be used instead of ``some_module.py``. .. important:: The filename of the produced extension module must not be changed as Python insists on a module name derived function as an entry point, in this case ``PyInit_some_module`` and renaming the file will not change that. Match the filename of the source code to what the binary name should be. .. note:: If both the extension module and the source code of it are in the same directory, the extension module is loaded. Changes to the source code only have effect once you recompile. .. note:: The option ``--follow-import-to`` works as well, but the included modules will only become importable *after* you imported the ``some_module`` name. If these kinds of imports are invisible to Nuitka, e.g. dynamically created, you can use ``--include-module`` or ``--include-package`` in that case, but for static imports it should not be needed. .. note:: An extension module can never include other extension modules. You will have to create a wheel for this to be doable. .. note:: The resulting extension module can only be loaded into a CPython of the same version and doesn't include other extension modules. Use Case 3 — Package compilation ================================== If you need to compile a whole package and embed all modules, that is also feasible, use Nuitka like this: .. code:: bash python -m nuitka --mode=module some_package --include-package=some_package .. note:: The inclusion of the package contents needs to be provided manually; otherwise, the package is mostly empty. You can be more specific if you like, and only include part of it, or exclude part of it, e.g. with ``--nofollow-import-to='*.tests'`` you would not include the unused test part of your code. .. note:: Data files located inside the package will not be embedded by this process, you need to copy them yourself with this approach. Alternatively, you can use the `file embedding of Nuitka commercial `__. Use Case 4 — Program Distribution =================================== For distribution to other systems, there is the standalone mode, which produces a folder for which you can specify ``--standalone``. .. code:: bash python -m nuitka --standalone program.py Following all imports is default in this mode. You can selectively exclude modules by specifically saying ``--nofollow-import-to``, but then an ``ImportError`` will be raised when import of it is attempted at program run time. This may cause different behavior, but it may also improve your compile time if done wisely. For data files to be included, use the option ``--include-data-files==`` where the source is a file system path, but the target has to be specified relative. For the standalone mode, you can also copy them manually, but this can do extra checks, and for the onefile mode, there is no manual copying possible. To copy some or all file in a directory, use the option ``--include-data-files=/etc/*.txt=etc/`` where you get to specify shell patterns for the files, and a subdirectory where to put them, indicated by the trailing slash. .. important:: Nuitka does not consider data files code, do not include DLLs, or Python files as data files, and expect them to work, they will not, unless you really know what you are doing. In the following, non-code data files are all files, not matching on of these criterions. +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | Suffix | Rationale | Solution | +============+========================================================================================+========================================================================================================+ | ``.py`` | Nuitka trims even the stdlib modules to be included. If it doesn't see Python code, | Use ``--include-module`` on them instead | | | there is no dependencies analyzed, and as a result it will just not work. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyc`` | Same as ``.py``. | Use ``--include-module`` on them from their source code instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyo`` | Same as ``.pyc``. | Use ``--include-module`` on them from their source code instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyw`` | Same as ``.py``. | For including multiple programs, use multiple ``--main`` arguments instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyi`` | These are ignored, because they are code-like and not needed at run time. For the | Raise an issue if 3rd part software needs it. | | | ``lazy`` package that actually would depend on them, we made a compile time solution | | | | that removes the need. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyx`` | These are ignored, because they are Cython source code not used at run time | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.dll`` | These are ignored, since they **usually** are not data files. For the cases where 3rd | Create Nuitka Package configuration for those, with ``dll`` section for the package that uses them. | | | party packages do actually used them as data, e.g. ``.NET`` packages, we solve that in | For rare cases, data-files section with special configuration might be the correct thing to do. | | | package configuration for it. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.dylib`` | These are ignored, since they macOS extension modules or DLLs. | Need to add configuration with ``dll`` section or ``depends`` that are missing | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.so`` | These are ignored, since they Linux, BSD, etc. extension modules or DLLs. | Need to add configuration with ``dll`` section or ``depends`` that are missing | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.exe`` | The are binaries to Windows. | You can add Nuitka Package configuration to include those as DLLs and mark them as ``executable: yes`` | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.bin`` | The are binaries to non-Windows, otherwise same as ``.exe``. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ Also folders are ignored, these are ``site-packages``, ``dist-packages`` and ``vendor-packages`` which would otherwise include a full virtualenv, which is never a good thing to happen. And the ``__pycache__`` folder is also always ignored. On non-MacOS the file ``.DS_Store`` is ignored too, and ``py.typed`` folders have only meaning to IDEs, and are ignored like ``.pyi`` files . To copy a whole folder with all non-code files, you can use ``--include-data-dir=/path/to/images=images`` which will place those in the destination, and if you want to use the ``--noinclude-data-files`` option to remove them. Code files are as detailed above DLLs, executables, Python files, etc. and will be ignored. For those you can use the ``--include-data-files=/binaries/*.exe=binary/`` form to force them, but that is not recommended and known to cause issues at run-time. For package data, there is a better way, namely using ``--include-package-data``, which detects all non-code data files of packages automatically and copies them over. It even accepts patterns in a shell style. It spares you the need to find the package directory yourself and should be preferred whenever available. Functionally it's very similar to ``--include-data-dir`` but it has the benefit to locate the correct folder for you. With data files, you are largely on your own. Nuitka keeps track of ones that are needed by popular packages, but it might be incomplete. Raise issues if you encounter something in these. Even better, raise PRs with enhancements to the Nuitka package configuration. We want 3rd party software to just work out of the box. When that is working, you can use the onefile mode if you so desire. .. code:: bash python -m nuitka --onefile program.py This will create a single binary, that extracts itself on the target, before running the program. But notice, that accessing files relative to your program is impacted, make sure to read the section `Onefile: Finding files`_ as well. .. code:: bash # Create a binary that unpacks into a temporary folder python -m nuitka --onefile program.py .. note:: There are more platform-specific options, e.g. related to icons, splash screen, and version information, consider the ``--help`` output for the details of these and check the section Tweaks_. For the unpacking, by default a unique user temporary path one is used, and then deleted, however this default ``--onefile-tempdir-spec="{TEMP}/onefile_{PID}_{TIME}"`` can be overridden with a path specification, then using a cached path, avoiding repeated unpacking, e.g. with ``--onefile-tempdir-spec="{CACHE_DIR}/{COMPANY}/{PRODUCT}/{VERSION}"`` which uses version information, and user-specific cache directory. .. note:: Using cached paths will be relevant, e.g. when Windows Firewall comes into play because otherwise, the binary will be a different one to it each time it is run. Currently, these expanded tokens are available: +----------------+-----------------------------------------------------------+---------------------------------------+ | Token | What this Expands to | Example | +================+===========================================================+=======================================+ | {TEMP} | User temporary file directory | C:\\Users\\...\\AppData\\Locals\\Temp | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PID} | Process ID | 2772 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {TIME} | Time in seconds since the epoch. | 1299852985 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM} | Full program run-time filename of executable. | C:\\SomeWhere\\YourOnefile.exe | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM_BASE} | No-suffix of run-time filename of executable. | C:\\SomeWhere\\YourOnefile | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM_DIR} | Containing directory of executable. | C:\\SomeWhere | +----------------+-----------------------------------------------------------+---------------------------------------+ | {CACHE_DIR} | Cache directory for the user. | C:\\Users\\SomeBody\\AppData\\Local | +----------------+-----------------------------------------------------------+---------------------------------------+ | {COMPANY} | Value given as ``--company-name`` | YourCompanyName | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PRODUCT} | Value given as ``--product-name`` | YourProductName | +----------------+-----------------------------------------------------------+---------------------------------------+ | {VERSION} | Combination of ``--file-version`` & ``--product-version`` | 3.0.0.0-1.0.0.0 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {HOME} | Home directory for the user. | /home/somebody | +----------------+-----------------------------------------------------------+---------------------------------------+ | {NONE} | When provided for file outputs, ``None`` is used | see notice below | +----------------+-----------------------------------------------------------+---------------------------------------+ | {NULL} | When provided for file outputs, ``os.devnull`` is used | see notice below | +----------------+-----------------------------------------------------------+---------------------------------------+ .. important:: It is your responsibility to make the path provided unique, on Windows a running program will be locked, and while using a fixed folder name is possible, it can cause locking issues in that case, where the program gets restarted. Usually, you need to use ``{TIME}`` or at least ``{PID}`` to make a path unique, and this is mainly intended for use cases, where e.g. you want things to reside in a place you choose or abide your naming conventions. .. important:: For disabling output and stderr with ``--force-stdout-spec`` and ``--force-stderr-spec`` the values ``{NONE}`` and ``{NULL}`` achieve it, but with different effect. With ``{NONE}``, the corresponding handle becomes ``None``. As a result, e.g. ``sys.stdout`` will be ``None``, which is different from ``{NULL}`` where it will be backed by a file pointing to ``os.devnull``, i.e. you can write to it. With ``{NONE}``, you may e.g. get ``RuntimeError: lost sys.stdout`` in case it does get used; with ``{NULL}`` that never happens. However, some libraries handle this as input for their logging mechanism, and on Windows this is how you are compatible with ``pythonw.exe`` which is behaving like ``{NONE}``. Use Case 5 — Setuptools Wheels ================================ If you have a ``setup.py``, ``setup.cfg`` or ``pyproject.toml`` driven creation of wheels for your software in place, putting Nuitka to use is extremely easy. Let's start with the most common ``setuptools`` approach, you can, having Nuitka installed of course, simply execute the target ``bdist_nuitka`` rather than the ``bdist_wheel``. It takes all the options and allows you to specify some more, that are specific to Nuitka. .. code:: python # For setup.py if you don't use other build systems: setup( # Data files are to be handled by setuptools and not Nuitka package_data={"some_package": ["some_file.txt"]}, ..., # This is to pass Nuitka options. command_options={ 'nuitka': { # boolean option, e.g. if you cared for C compilation commands '--show-scons': True, # options without value, e.g. enforce using Clang '--clang': None, # options with single values, e.g. enable a plugin of Nuitka '--enable-plugin': "pyside2", # options with several values, e.g. avoid including modules '--nofollow-import-to' : ["*.tests", "*.distutils"], }, }, ) # For setup.py with other build systems: # The tuple nature of the arguments is required by the dark nature of # "setuptools" and plugins to it, that insist on full compatibility, # e.g. "setuptools_rust" setup( # Data files are to be handled by setuptools and not Nuitka package_data={"some_package": ["some_file.txt"]}, ..., # This is to pass Nuitka options. ..., command_options={ 'nuitka': { # boolean option, e.g. if you cared for C compilation commands '--show-scons': ("setup.py", True), # options without value, e.g. enforce using Clang '--clang': ("setup.py", None), # options with single values, e.g. enable a plugin of Nuitka '--enable-plugin': ("setup.py", "pyside2"), # options with several values, e.g. avoid including modules '--nofollow-import-to' : ("setup.py", ["*.tests", "*.distutils"]), } }, ) If for some reason, you cannot or do not want to change the target, you can add this to your ``setup.py``. .. code:: python # For setup.py setup( ..., build_with_nuitka=True ) .. note:: To temporarily disable the compilation, you could the remove above line, or edit the value to ``False`` by or take its value from an environment variable if you so choose, e.g. ``bool(os.getenv("USE_NUITKA", "True"))``. This is up to you. Or you could put it in your ``setup.cfg`` .. code:: toml [metadata] build_with_nuitka = true And last, but not least, Nuitka also supports the new ``build`` meta, so when you have a ``pyproject.toml`` already, simple replace or add this value: .. code:: toml [build-system] requires = ["setuptools>=42", "wheel", "nuitka", "toml"] build-backend = "nuitka.distutils.Build" # Data files are to be handled by setuptools and not Nuitka [tool.setuptools.package-data] some_package = ['data_file.txt'] [tool.nuitka] # These are not recommended, but they make it obvious to have effect. # boolean option, e.g. if you cared for C compilation commands, leading # dashes are omitted show-scons = true # options with single values, e.g. enable a plugin of Nuitka enable-plugin = "pyside2" # options with several values, e.g. avoid including modules, accepts # list argument. nofollow-import-to = ["*.tests", "*.distutils"] .. note:: For the ``nuitka`` requirement above absolute paths like ``C:\Users\...\Nuitka`` will also work on Linux, use an absolute path with *two* leading slashes, e.g. ``//home/.../Nuitka``. .. note:: Whatever approach you take, data files in these wheels are not handled by Nuitka at all, but by setuptools. You can, however, use the data file embedding of Nuitka commercial. In that case, you actually would embed the files inside the extension module itself, and not as a file in the wheel. Use Case 6 — Multidist ======================== If you have multiple programs, that each should be executable, in the past you had to compile multiple times, and deploy all of these. With standalone mode, this, of course, meant that you were fairly wasteful, as sharing the folders could be done, but wasn't really supported by Nuitka. Enter ``Multidist``. There is an option ``--main`` that replaces or adds to the positional argument given. And it can be given multiple times. When given multiple times, Nuitka will create a binary that contains the code of all the programs given, but sharing modules used in them. They therefore do not have to be distributed multiple times. Let's call the basename of the main path, and entry point. The names of these must, of course, be different. Then the created binary can execute either entry point, and will react to what ``sys.argv[0]`` appears to it. So if executed in the right way (with something like ``subprocess`` or OS API you can control this name), or by renaming or copying the binary, or symlinking to it, you can then achieve the miracle. This allows to combine very different programs into one. .. note:: This feature is still experimental. Use with care and report your findings should you encounter anything that is undesirable behavior This mode works with standalone, onefile, and mere acceleration. It does not work with module mode. Use Case 7 — Building with GitHub Workflows ============================================= For integration with GitHub workflows there is this `Nuitka-Action `__ that you should use that makes it really easy to integrate. You ought to start with a local compilation though, but this will be easiest for cross platform compilation with Nuitka. This is an example workflow that builds on all 3 OSes .. code:: yaml jobs: build: strategy: matrix: os: [macos-latest, ubuntu-latest, windows-latest] runs-on: ${{ matrix.os }} steps: - name: Check-out repository uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: '3.10' cache: 'pip' cache-dependency-path: | **/requirements*.txt - name: Install your Dependencies run: | pip install -r requirements.txt -r requirements-dev.txt - name: Build Executable with Nuitka uses: Nuitka/Nuitka-Action@main with: nuitka-version: main script-name: your_main_program.py # many more Nuitka options available, see action doc, but it's best # to use nuitka-project: options in your code, so e.g. you can make # a difference for macOS and create an app bundle there. mode: onefile - name: Upload Artifacts uses: actions/upload-artifact@v4 with: name: ${{ runner.os }} Build path: | # match what's created for the 3 OSes build/*.exe build/*.bin build/*.app/**/* If you app is a GUI, e.g. ``your_main_program.py`` should contain these comments as explained in `Nuitka Options in the code`_ since on macOS this should then be a bundle. .. code:: python # Compilation mode, standalone everywhere, except on macOS there app bundle # nuitka-project-if: {OS} in ("Windows", "Linux", "FreeBSD"): # nuitka-project: --onefile # nuitka-project-if: {OS} == "Darwin": # nuitka-project: --standalone # nuitka-project: --macos-create-app-bundle # .. note:: This is best expression with ``nuitka-project: --mode=app`` which encapsulates these options. ******** Tweaks ******** Icons ===== For good looks, you may specify icons. On Windows, you can provide an icon file, a template executable, or a PNG file. All of these will work and may even be combined: .. code:: bash # These create binaries with icons on Windows python -m nuitka --onefile --windows-icon-from-ico=your-icon.png program.py python -m nuitka --onefile --windows-icon-from-ico=your-icon.ico program.py python -m nuitka --onefile --windows-icon-template-exe=your-icon.ico program.py # These create application bundles with icons on macOS python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.png program.py python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.icns program.py .. note:: With Nuitka, you do not have to create platform-specific icons, but instead it will convert e.g. PNG, but also other formats on the fly during the build. MacOS Entitlements ================== Entitlements for an macOS application bundle can be added with the option, ``--macos-app-protected-resource``, all values are listed on `this page from Apple `__ An example value would be ``--macos-app-protected-resource=NSMicrophoneUsageDescription:Microphone access`` for requesting access to a Microphone. After the colon, the descriptive text is to be given. .. note:: Beware that in the likely case of using spaces in the description part, you need to quote it for your shell to get through to Nuitka and not be interpreted as Nuitka arguments. Console Window ============== On Windows, the console is not opened by programs unless you say so. Nuitka defaults to not show it, you can force it by using ``--console=force`` though, then the program will open a new terminal Window when its executed. Splash screen ============= Splash screens are useful when program startup is slow. Onefile startup itself is not slow, but your program may be, and you cannot really know how fast the computer used will be, so it might be a good idea to have them. Luckily, with Nuitka, they are easy to add for Windows. For the splash screen, you need to specify it as a PNG file, and then make sure to disable the splash screen when your program is ready, e.g. has completed the imports, prepared the window, connected to the database, and wants the splash screen to go away. Here we are using the project syntax to combine the code with the creation, compile this: .. code:: python # nuitka-project: --mode=onefile # nuitka-project: --mode=onefile-windows-splash-screen-image={MAIN_DIRECTORY}/Splash-Screen.png # Whatever this is, obviously print("Delaying startup by 10s...") import time, tempfile, os time.sleep(10) # Use this code to signal the splash screen removal. if "NUITKA_ONEFILE_PARENT" in os.environ: splash_filename = os.path.join( tempfile.gettempdir(), "onefile_%d_splash_feedback.tmp" % int(os.environ["NUITKA_ONEFILE_PARENT"]), ) if os.path.exists(splash_filename): os.unlink(splash_filename) print("Done... splash should be gone.") ... # Rest of your program goes here. Reports ======= For analysis of your program and Nuitka packaging, there is the `Compilation Report`_ available. You can also make custom reports by providing your template, with a few of them built-in to Nuitka. These reports carry all the detail information, e.g. when a module was attempted to be imported, but not found, you can see where that happens. For bug reporting, it is very much recommended to provide the report. Version Information =================== You can attach copyright and trademark information, company name, product name, and so on to your compilation. This is then used in version information for the created binary on Windows, or application bundle on macOS. If you find something that is lacking, please let us know. ****************** Typical Problems ****************** Deployment Mode =============== By default, Nuitka compiles without ``--deployment`` which leaves a set of safe guards and helpers on, that are aimed at debugging wrong uses of Nuitka. This is a new feature, and implements a bunch of protections and helpers, that are documented here. Fork bombs (self-execution) --------------------------- So after compilation, ``sys.executable`` is the compiled binary. In case of packages like ``multiprocessing``, ``joblib``, or ``loky`` what these typically do is to expect to run from a full ``python`` with ``sys.executable`` and then to be able to use its options like ``-c command`` or ``-m module_name`` and then be able to launch other code temporarily or permanently as a service daemon. With Nuitka however, this executes your program again, and puts these arguments, in ``sys.argv`` where you maybe ignore them, and then you fork yourself again to launch the helper daemons. Sometimes this ends up spawning CPU count processes that spawn CPU count processes that... this is called a fork bomb, and with almost all systems, that freezes them easily to death. That is why e.g. this happens with default Nuitka: .. code:: ./hello.dist/hello.bin -l fooL -m fooM -n fooN -o fooO -p Error, the program tried to call itself with '-m' argument. Disable with '--no-deployment-flag=self-execution'. Your program may well have its own command line parsing, and not use an unsupported package that does attempt to re-execute. In this case, you need at *compile time* to use ``--no-deployment-flag=self-execution`` which disables this specific guard. Misleading Messages ------------------- Some packages output what they think is helpful information about what the reason of a failed import might mean. With compiled programs there are very often just plain wrong. We try and repair those in non-deployment mode. Here is an example, where we change a message that asks to pip install (which is not the issue) to point the user to the include command that makes an ``imageio`` plugin work. .. code:: yaml - module-name: 'imageio.core.imopen' anti-bloat: - replacements_plain: '`pip install imageio[{config.install_name}]` to install it': '`--include-module={config.module_name}` with Nuitka to include it' 'err_type = ImportError': 'err_type = RuntimeError' when: 'not deployment' And much more ------------- The deployment mode is relatively new and has constantly more features added, e.g. something for ``FileNotFoundError`` should be coming soon. Disabling All ------------- All these helpers can of course be disabled at once with ``--deployment`` but keep in mind that for debugging, you may want to re-enable it. You might want to use Nuitka Project options and an environment variable to make this conditional. Should you disable them all? We believe, disabling should only happen selectively, but with PyPI upgrades, your code changes, all of these issues can sneak back in. The space saving of deployment mode is currently negligible, so attempt to not do it, but review what exists, and if you know that it cannot affect you, or if it does, you will not need it. Some of the future ones, will clearly be geared at beginner level usage. Windows Virus scanners ====================== Binaries compiled on Windows with default settings of Nuitka and no further actions taken might be recognized by some AV vendors as malware. This is avoidable, but only in Nuitka commercial there is actual support and instructions for how to do it, seeing this as a typical commercial only need. https://nuitka.net/doc/commercial.html Linux Standalone ================ For Linux standalone it is pretty difficult to build a binary that works on other Linux versions. This is mainly because on Linux, much software is built specifically targeted to concrete DLLs. Things like glibc used, are then encoded into the binary built, and it will not run with an older glibc, just to give one critical example. The solution is to build on the oldest OS that you want to see supported. Picking that and setting it up can be tedious, so can be login, and keeping it secure, as it's something you put your source code on. To aid that, Nuitka commercial has container based builds, that you can use. This uses dedicated optimized Python builds, targets CentOS 7 and supports even newest Pythons and very old OSes that way using recent C compiler chains all turn key solution. The effort needs to be compensated to support Nuitka development for Linux, there you need to purchase it https://nuitka.net/doc/commercial.html but even a sponsor license will be cheaper than doing it yourself. Program crashes system (fork bombs) =================================== A fork bomb is a program that starts itself over and over. This can easily happen, since ``sys.executable`` for compiled programs is not a Python interpreter, and packages that try to do multiprocessing in a better way, often relaunch themselves through this, and Nuitka needs and does have handling for these with known packages. However, you may encounter a situation where the detection of this fails. See deployment option above that is needed to disable this protection. When this fork bomb happens easily all memory, all CPU of the system that is available to the user is being used, and even the most powerful build system will go down in flames sometimes needing a hard reboot. For fork bombs, we can use ``--experimental=debug-self-forking`` and see what it does, and we have a trick, that prevents fork bombs from having any actual success in their bombing. Put this at the start of your program. .. code:: python import os, sys if "NUITKA_LAUNCH_TOKEN" not in os.environ: sys.exit("Error, need launch token or else fork bomb suspected.") else: del os.environ["NUITKA_LAUNCH_TOKEN"] Actually Nuitka is trying to get ahold of them without the deployment option already, finding "-c" and "-m" options, but it may not be perfect or not work well with a package (anymore). Memory issues and compiler bugs =============================== In some cases, the C compilers will crash saying they cannot allocate memory or that some input was truncated, or similar error messages, clearly from it. These are example error messages, that are a sure sign of too low memory, there is no end to them. .. code:: # gcc fatal error: error writing to -: Invalid argument Killed signal terminated program # MSVC fatal error C1002: compiler is out of heap space in pass 2 fatal error C1001: Internal compiler error There are several options you can explore here. Ask Nuitka to use less memory ----------------------------- There is a dedicated option ``--low-memory`` which influences decisions of Nuitka, such that it avoids high usage of memory during compilation at the cost of increased compile time. Avoid 32 bit C compiler/assembler memory limits ----------------------------------------------- Do not use a 32 bit compiler, but a 64 bit one. If you are using Python with 32 bits on Windows, you most definitely ought to use MSVC as the C compiler, and not MinGW64. The MSVC is a cross-compiler, and can use more memory than gcc on that platform. If you are not on Windows, that is not an option, of course. Also, using the 64 bit Python will work. Use a minimal virtualenv ------------------------ When you compile from a living installation, that may well have many optional dependencies of your software installed. Some software will then have imports on these, and Nuitka will compile them as well. Not only may these be just the troublemakers, they also require more memory, so get rid of that. Of course, you do have to check that your program has all the needed dependencies before you attempt to compile, or else the compiled program will equally not run. Use LTO compilation or not -------------------------- With ``--lto=yes`` or ``--lto=no`` you can switch the C compilation to only produce bytecode, and not assembler code and machine code directly, but make a whole program optimization at the end. This will change the memory usage pretty dramatically, and if your error is coming from the assembler, using LTO will most definitely avoid that. Switch the C compiler to clang ------------------------------ People have reported that programs that fail to compile with gcc due to its bugs or memory usage work fine with clang on Linux. On Windows, this could still be an option, but it needs to be implemented first for the automatic downloaded gcc, that would contain it. Since MSVC is known to be more memory effective anyway, you should go there, and if you want to use Clang, there is support for the one contained in MSVC. Add a larger swap file to your embedded Linux --------------------------------------------- On systems with not enough RAM, you need to use swap space. Running out of it is possibly a cause, and adding more swap space, or one at all, might solve the issue, but beware that it will make things extremely slow when the compilers swap back and forth, so consider the next tip first or on top of it. Limit the amount of compilation jobs ------------------------------------ With the ``--jobs`` option of Nuitka, it will not start many C compiler instances at once, each competing for the scarce resource of RAM. By picking a value of one, only one C compiler instance will be running, and on an 8 core system, that reduces the amount of memory by factor 8, so that's a natural choice right there. Dynamic ``sys.path`` ==================== If your script modifies ``sys.path``, e.g. inserts directories with source code relative to it, Nuitka will not be able to see those. However, if you set the ``PYTHONPATH`` to the resulting value, it will be able to compile it and find the used modules from these paths as well. Manual Python File Loading ========================== A very frequent pattern with private code is that it scans plugin directories of some kind, and e.g. uses ``os.listdir``, then considers Python filenames, and then opens a file and does ``exec`` on them. This approach works for Python code, but for compiled code, you should use this much cleaner approach, that works for pure Python code and is a lot less vulnerable. .. code:: python # Using a package name, to locate the plugins. This is also a sane # way to organize them into a directory. scan_path = scan_package.__path__ for item in pkgutil.iter_modules(scan_path): importlib.import_module(scan_package.__name__ + "." + item.name) # You may want to do it recursively, but we don't do this here in # this example. If you'd like to, handle that in this kind of branch. if item.ispkg: ... Missing data files in standalone ================================ If your program fails to find data file, it can cause all kinds of different behavior, e.g. a package might complain it is not the right version because a ``VERSION`` file check defaulted to an unknown. The absence of icon files or help texts, may raise strange errors. Often the error paths for files not being present are even buggy and will reveal programming errors like unbound local variables. Please look carefully at these exceptions, keeping in mind that this can be the cause. If your program works without standalone, chances are data files might be the cause. The most common error indicating file absence is of course an uncaught ``FileNotFoundError`` with a filename. You should figure out what package is missing files and then use ``--include-package-data`` (preferably), or ``--include-data-dir``/``--include-data-files`` to include them. Missing DLLs/EXEs in standalone =============================== Nuitka has plugins that deal with copying DLLs. For NumPy, SciPy, Tkinter, etc. These need special treatment to be able to run on other systems. Manually copying them is not enough and will give strange errors. Sometimes newer version of packages, esp. NumPy can be unsupported. In this case, you will have to raise an issue, and use the older one. If you want to manually add a DLL or an EXE because it is your project only, you will have to use user Yaml files describing where they can be found. This is described in detail with examples in the `Nuitka Package Configuration `__ page. Dependency creep in standalone ============================== Some packages are a single import, but to Nuitka mean that more than a thousand packages (literally) are to be included. The prime example of Pandas, which does want to plug and use just about everything you can imagine. Multiple frameworks for syntax highlighting everything imaginable take time. Nuitka will have to learn effective caching to deal with this in the future. Presently, you will have to deal with huge compilation times for these. A major weapon in fighting dependency creep should be applied, namely the ``anti-bloat`` plugin, which offers interesting abilities, that can be put to use and block unneeded imports, giving an error for where they occur. Use it e.g. like this ``--noinclude-pytest-mode=nofollow --noinclude-setuptools-mode=nofollow`` and e.g. also ``--noinclude-custom-mode=setuptools:error`` to get the compiler to error out for a specific package. Make sure to check its help output. It can take for each module of your choice, e.g. forcing also that e.g. ``PyQt5`` is considered uninstalled for standalone mode. It's also driven by a configuration file, ``anti-bloat.yml`` that you can contribute to, removing typical bloat from packages. Please don't hesitate to enhance it and make PRs towards Nuitka with it. Standalone: Finding files ========================= The standard code that normally works, also works, you should refer to ``os.path.dirname(__file__)`` or use all the packages like ``pkgutil``, ``pkg_resources``, ``importlib.resources`` to locate data files near the standalone binary. .. important:: What you should **not** do, is use the current directory ``os.getcwd``, or assume that this is the script directory, e.g. with paths like ``data/``. If you did that, it was never good code. Links, to a program, launching from another directory, etc. will all fail in bad ways. Do not make assumptions about the directory your program is started from. In case you mean to refer to the location of the ``.dist`` folder for files that are to reside near the binary, there is ``__compiled__.containing_dir`` that also abstracts all differences with ``--macos-create-app-bundle`` and the ``.app`` folder a having more nested structure. .. code:: python # This will find a file *near* your app or dist folder try: open(os.path.join(__compiled__.containing_dir, "user-provided-file.txt")) except NameError: open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) Onefile: Finding files ====================== There is a difference between ``sys.argv[0]`` and ``__file__`` of the main module for the onefile mode, that is caused by using a bootstrap to a temporary location. The first one will be the original executable path, whereas the second one will be the temporary or permanent path the bootstrap executable unpacks to. Data files will be in the later location, your original environment files will be in the former location. Given 2 files, one which you expect to be near your executable, and one which you expect to be inside the onefile binary, access them like this. .. code:: python # This will find a file *near* your onefile.exe open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) # This will find a file *inside* your onefile.exe open(os.path.join(os.path.dirname(__file__), "user-provided-file.txt")) # This will find a file *near* your onefile binary and work for standalone too try: open(os.path.join(__compiled__.containing_dir, "user-provided-file.txt")) except NameError: open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) .. note:: When the program is launched from the executable, the original ``sys.argv[0]`` from the invocation command line will not be preserved, it will be made an absolute path. For advanced use cases where one needs access to the original ``sys.argv[0]``, it may be found at ``__compiled__.original_argv0``. The field will read back as ``None`` if the program is not launched from the onefile executable, thus not having gone through the onefile bootstrap stage; the original ``sys.argv[0]`` would be preserved as well in this case. .. code:: python # Suppose the onefile binary is placed at /opt/abc/bin/foo, and it was # symlinked to /usr/local/bin/bar, and invoked as `bar ...`: assert sys.argv[0] == "/usr/local/bin/bar" assert __compiled__.original_argv0 == "bar" # If the onefile tempdir is overridden and the program is invoked # directly from the unpacked location, sys.argv[0] would not be touched. # # Suppose the onefile tempdir is /home/xx/.cache/abc/0.1.2, and the # foo.bin executable inside is symlinked to /usr/local/bin/baz, and # invoked as `baz ...`: assert sys.argv[0] == "baz" assert __compiled__.original_argv0 is None Windows Programs without console give no errors =============================================== For debugging purposes, use the options ``--force-stdout-spec`` and ``--force-stderr-spec`` with paths as documented for ``--onefile-tempdir-spec`` above. These can be relative to the program or absolute, so you can see the outputs given. Also you can run the program on a terminal prompt like ``CMD.exe`` to see its outputs. Deep copying uncompiled functions ================================= Sometimes people use this kind of code, which for packages on PyPI, we deal with by doing source code patches on the fly. If this is in your own code, here is what you can do: .. code:: python def binder(func, name): result = types.FunctionType(func.__code__, func.__globals__, name=func.__name__, argdefs=func.__defaults__, closure=func.__closure__) result = functools.update_wrapper(result, func) result.__kwdefaults__ = func.__kwdefaults__ result.__name__ = name return result Compiled functions cannot be used to create uncompiled ones from, so the above code will not work. However, there is a dedicated ``clone`` method, that is specific to them, so use this instead. .. code:: python def binder(func, name): try: result = func.clone() except AttributeError: result = types.FunctionType(func.__code__, func.__globals__, name=func.__name__, argdefs=func.__defaults__, closure=func.__closure__) result = functools.update_wrapper(result, func) result.__kwdefaults__ = func.__kwdefaults__ result.__name__ = name return result Modules: Extension modules are not executable directly ====================================================== A package can be compiled with Nuitka, no problem, but when it comes to executing it, ``python -m compiled_module`` is not going to work and give the error ``No code object available for AssertsTest`` because the compiled module is not source code, and Python will not just load it. The closest would be ``python -c "import compile_module"`` and you might have to call the main function yourself. To support this, the CPython ``runpy`` and/or ``ExtensionFileLoader`` would need improving such that Nuitka could supply its compiled module object for Python to use. ****** Tips ****** Nuitka Options in the code ========================== One clean way of providing options to Nuitka, that you will always use for your program, is to put them into the main file you compile. There is even support for conditional options, and options using pre-defined variables, this is an example: .. code:: python # Compilation mode, support OS-specific options # nuitka-project-if: {OS} in ("Windows", "Linux", "Darwin", "FreeBSD"): # nuitka-project: --mode=app # nuitka-project-else: # nuitka-project: --mode=standalone # The PySide2 plugin covers qt-plugins # nuitka-project: --enable-plugin=pyside2 # nuitka-project: --include-qt-plugins=qml The comments must be at the start of lines, and indentation inside of them is to be used, to end a conditional block, much like in Python. There are currently no other keywords than the used ones demonstrated above. You can put arbitrary Python expressions there, and if you wanted to e.g. access a version information of a package, you could simply use ``__import__("module_name").__version__`` if that would be required to e.g. enable or disable certain Nuitka settings. The only thing Nuitka does that makes this not Python expressions, is expanding ``{variable}`` for a pre-defined set of variables: Table with supported variables: +------------------+--------------------------------+------------------------------------------+ | Variable | What this Expands to | Example | +==================+================================+==========================================+ | {OS} | Name of the OS used | Linux, Windows, Darwin, FreeBSD, OpenBSD | +------------------+--------------------------------+------------------------------------------+ | {Version} | Version of Nuitka | e.g. (1, 6, 0) | +------------------+--------------------------------+------------------------------------------+ | {Commercial} | Version of Nuitka Commercial | e.g. (2, 1, 0) | +------------------+--------------------------------+------------------------------------------+ | {Arch} | Architecture used | x86_64, arm64, etc. | +------------------+--------------------------------+------------------------------------------+ | {MAIN_DIRECTORY} | Directory of the compiled file | some_dir/maybe_relative | +------------------+--------------------------------+------------------------------------------+ | {Flavor} | Variant of Python | e.g. Debian Python, Anaconda Python | +------------------+--------------------------------+------------------------------------------+ The use of ``{MAIN_DIRECTORY}`` is recommended when you want to specify a filename relative to the main script, e.g. for use in data file options or user package configuration yaml files, .. code:: python # nuitka-project: --include-data-files={MAIN_DIRECTORY}/my_icon.png=my_icon.png # nuitka-project: --user-package-configuration-file={MAIN_DIRECTORY}/user.nuitka-package.config.yml Python command line flags ========================= For passing things like ``-O`` or ``-S`` to Python, to your compiled program, there is a command line option name ``--python-flag=`` which makes Nuitka emulate these options. The most important ones are supported, more can certainly be added. Caching compilation results =========================== The C compiler, when invoked with the same input files, will take a long time and much CPU to compile over and over. Make sure you are having ``ccache`` installed and configured when using gcc (even on Windows). It will make repeated compilations much faster, even if things are not yet perfect, i.e. changes to the program can cause many C files to change, requiring a new compilation instead of using the cached result. On Windows, with gcc, Nuitka supports using ``ccache.exe``, which it will offer to download from an official source and install it automatically. This is the recommended way of using it on Windows, as other versions may cause issues e.g. hanging. Nuitka will pick up ``ccache`` if it's found in system ``PATH``, and it will also be possible to provide if by setting ``NUITKA_CCACHE_BINARY`` to the full path of the binary, this is for use in CI systems where environments might be non-standard. For the MSVC compilers and ClangCL setups, using the ``clcache`` is automatic and included in Nuitka. On macOS and Intel, there is an automatic download of a ``ccache`` binary from our site, for arm64 arches, it's recommended to use this setup, which installs Homebrew and ccache in there. Nuitka picks that one up automatically if it on that kind of machine. You need and should not use Homebrew with Nuitka otherwise, it's not the best for standalone deployments, but we can take ``ccache`` from there. .. code:: bash export HOMEBREW_INSTALL_FROM_API=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" eval $(/opt/homebrew/bin/brew shellenv) brew install ccache Control where Caches live ========================= The storage for cache results of all kinds, downloads, cached compilation results from C and Nuitka, is done in a platform dependent directory as determined by the ``appdirs`` package. However, you can override it with setting the environment variable ``NUITKA_CACHE_DIR`` to a base directory. This is for use in environments where the home directory is not persisted, but other paths are. There is also per cache control of these caches, here is a table of environment variables that you can set before starting the compilation, to make Nuitka store some of these caches in an entirely separate space. +------------------+-----------------------------------+----------------------------------------+ | Cache name | Environment Variable | Data Put there | +==================+===================================+========================================+ | downloads | NUITKA_CACHE_DIR_DOWNLOADS | Downloads made, e.g. dependency walker | +------------------+-----------------------------------+----------------------------------------+ | ccache | NUITKA_CACHE_DIR_CCACHE | Object files created by gcc | +------------------+-----------------------------------+----------------------------------------+ | clcache | NUITKA_CACHE_DIR_CLCACHE | Object files created by MSVC | +------------------+-----------------------------------+----------------------------------------+ | bytecode | NUITKA_CACHE_DIR_BYTECODE | Bytecode of demoted modules | +------------------+-----------------------------------+----------------------------------------+ | dll-dependencies | NUITKA_CACHE_DIR_DLL_DEPENDENCIES | DLL dependencies | +------------------+-----------------------------------+----------------------------------------+ Runners ======= Avoid running the ``nuitka`` binary, doing ``python -m nuitka`` will make a 100% sure you are using what you think you are. Using the wrong Python will make it give you ``SyntaxError`` for good code or ``ImportError`` for installed modules. That is happening, when you run Nuitka with Python2 on Python3 code and vice versa. By explicitly calling the same Python interpreter binary, you avoid that issue entirely. Fastest C Compilers =================== The fastest binaries of ``pystone.exe`` on Windows with 64 bits Python proved to be significantly faster with MinGW64, roughly 20% better score. So it is recommended for use over MSVC. Using ``clang-cl.exe`` of Clang7 was faster than MSVC, but still significantly slower than MinGW64, and it will be harder to use, so it is not recommended. On Linux, for ``pystone.bin``, the binary produced by ``clang6`` was faster than ``gcc-6.3``, but not by a significant margin. Since gcc is more often already installed, that is recommended to use for now. Differences in C compilation times have not yet been examined. Unexpected Slowdowns ==================== Using the Python DLL, like standard CPython does, can lead to unexpected slowdowns, e.g. in uncompiled code that works with Unicode strings. This is because calling to the DLL rather than residing in the DLL causes overhead, and this even happens to the DLL with itself, being slower, than a Python all contained in one binary. So if feasible, aim at static linking, which is currently only possible with Anaconda Python on non-Windows, Debian Python2, self compiled Pythons (do not activate ``--enable-shared``, not needed), and installs created with ``pyenv``. .. note:: On Anaconda, you may need to execute ``conda install libpython-static`` Standalone executables and dependencies ======================================= The process of making standalone executables for Windows traditionally involves using an external dependency walker to copy necessary libraries along with the compiled executables to the distribution folder. There are plenty of ways to find that something is missing. Do not manually copy things into the folder, esp. not DLLs, as that's not going to work. Instead, make bug reports to get these handled by Nuitka properly. Windows errors with resources ============================= On Windows, the Windows Defender tool and the Windows Indexing Service both scan the freshly created binaries, while Nuitka wants to work with it, e.g. adding more resources, and then preventing operations randomly due to holding locks. Make sure to exclude your compilation stage from these services. Windows standalone program redistribution ========================================= Whether compiling with MingW or MSVC, the standalone programs have external dependencies to Visual C Runtime libraries. Nuitka tries to ship those dependent DLLs by copying them from your system. Beginning with Microsoft Windows 10, Microsoft ships ``ucrt.dll`` (Universal C Runtime libraries) which handles calls to ``api-ms-crt-*.dll``. With earlier Windows platforms (and wine/ReactOS), you should consider installing Visual C runtime libraries before executing a Nuitka standalone compiled program. Depending on the used C compiler, you'll need the following redist versions on the target machines. However, notice that compilation using the 14.3 based version is always recommended, working and best supported, unless you want to target Windows 7. +------------------+-------------+----------+ | Visual C version | Redist Year | CPython | +==================+=============+==========+ | 14.3 | 2022 | 3.11 | +------------------+-------------+----------+ | 14.2 | 2019 | 3.5-3.10 | +------------------+-------------+----------+ | 14.1 | 2017 | 3.5-3.8 | +------------------+-------------+----------+ | 14.0 | 2015 | 3.5-3.8 | +------------------+-------------+----------+ | 10.0 | 2010 | 3.4 | +------------------+-------------+----------+ | 9.0 | 2008 | 2.6, 2.7 | +------------------+-------------+----------+ When using MingGW64 as downloaded by Nuitka, you'll need the following redist versions: +----------------------------+-------------+---------------------+ | MingGW64 version | Redist Year | CPython | +============================+=============+=====================+ | WinLibs automatic download | 2015 | 2.6, 2.7, 3.4- 3.11 | +----------------------------+-------------+---------------------+ Once the corresponding runtime libraries are installed on the target system, you may remove all ``api-ms-crt-*.dll`` files from your Nuitka compiled dist folder. Detecting Nuitka at run time ============================ Nuitka does *not* ``sys.frozen`` unlike other tools because it usually triggers inferior code for no reason. For Nuitka, we have the module attribute ``__compiled__`` to test if a specific module was compiled, and the function attribute ``__compiled__`` to test if a specific function was compiled. Providing extra Options to Nuitka C compilation =============================================== Nuitka will apply values from the environment variables ``CCFLAGS``, ``LDFLAGS`` during the compilation on top of what it determines to be necessary. Beware, of course, that this is only useful if you know what you are doing, so should this pose issues, raise them only with perfect information. Producing a 32 bit binary on a 64 bit Windows system ==================================================== Nuitka will automatically target the architecture of the Python you are using. If this is 64 bit, it will create a 64 bit binary, if it is 32 bit, it will create a 32 bit binary. You have the option to select the bits when you download the Python. In the output of ``python -m nuitka --version`` there is a line for the architecture. It's ``Arch: x86_64`` for 64 bits, and just ``Arch: x86`` for 32 bits. The C compiler will be picked to match that more or less automatically. If you specify it explicitly, and it mismatches, you will get a warning about the mismatch and informed that your compiler choice was rejected. ******************** Compilation Report ******************** When you use ``--report=compilation-report.xml`` Nuitka will create an XML file with detailed information about the compilation and packaging process. This is growing in completeness with every release and exposes module usage attempts, timings of the compilation, plugin influences, data file paths, DLLs, and reasons why things are included or not. At this time, the report contains absolute paths in some places, with your private information. The goal is to make this blended out by default because we also want to become able to compare compilation reports from different setups, e.g. with updated packages, and see the changes to Nuitka. The report is, however, recommended for your bug reporting. Also, another form is available, where the report is free form and according to a Jinja2 template of yours, and one that is included in Nuitka. The same information as used to produce the XML file is accessible. However, right now, this is not yet documented, but we plan to add a table with the data. For a reader of the source code that is familiar with Jinja2, however, it will be easy to do it now already. If you have a template, you can use it like this ``--report-template=your_template.rst.j2:your_report.rst`` and of course, the usage of restructured text, is only an example. You can use Markdown, your own XML, or whatever you see fit. Nuitka will just expand the template with the compilation report data. Currently, the following reports are included in Nuitka. You just use the name as a filename, and Nuitka will pick that one instead. +---------------+--------------+--------------------------------------------------------+ | Report Name | Status | Purpose | +===============+==============+========================================================+ | LicenseReport | experimental | Distributions used in a compilation with license texts | +---------------+--------------+--------------------------------------------------------+ .. note:: The community can and should contribute more report types and help enhancing the existing ones for good looks. ************* Performance ************* This chapter gives an overview, of what to currently expect in terms of performance from Nuitka. It's a work in progress and is updated as we go. The current focus for performance measurements is Python 2.7, but 3.x is going to follow later. pystone results =============== The results are the top value from this kind of output, running pystone 1000 times and taking the minimal value. The idea is that the fastest run is most meaningful, and eliminates usage spikes. .. code:: bash echo "Uncompiled Python2" for i in {1..100}; do BENCH=1 python2 tests/benchmarks/pystone.py ; done | sort -rn | head -n 1 python2 -m nuitka --lto=yes --pgo-c tests/benchmarks/pystone.py echo "Compiled Python2" for i in {1..100}; do BENCH=1 ./pystone.bin ; done | sort -n | head -rn 1 PYTHON3=python3.10 # Using a 100 gives semi-reliable values already, 1000 for best accuracy. RUNS=1000 $PYTHON3 -m nuitka --lto=yes --pgo-c --static-libpython=yes tests/benchmarks/pystone3.py echo "Uncompiled $PYTHON3" for i in $(seq 1 $RUNS); do BENCH=1 $PYTHON3 tests/benchmarks/pystone3.py ; done | sort -rn | head -n 1 echo "Compiled $PYTHON3" for i in $(seq 1 $RUNS); do BENCH=1 ./pystone3.bin ; done | sort -rn | head -n 1 +-------------------+-------------------+----------------------+---------------------+ | Python | Uncompiled | Compiled LTO | Compiled PGO | +===================+===================+======================+=====================+ | Debian Python 2.7 | 137497.87 (1.000) | 460995.20 (3.353) | 503681.91 (3.663) | +-------------------+-------------------+----------------------+---------------------+ | Nuitka Python 2.7 | 144074.78 (1.048) | 479271.51 (3.486) | 511247.44 (3.718) | +-------------------+-------------------+----------------------+---------------------+ Report issues or bugs ===================== Should you encounter any issues, bugs, or ideas, please visit the `Nuitka bug tracker `__ and report them. Best practices for reporting bugs: - Please always include the following information in your report, for the underlying Python version. You can easily copy&paste this into your report. It does contain more information than you think. Do not write something manually. You may always add, of course, .. code:: bash python -m nuitka --version - Try to make your example minimal. That is, try to remove code that does not contribute to the issue as much as possible. Ideally, come up with a small reproducing program that illustrates the issue, using ``print`` with different results when the program runs compiled or native. - If the problem occurs spuriously (i.e. not each time), try to set the environment variable ``PYTHONHASHSEED`` to ``0``, disabling hash randomization. If that makes the problem go away, try increasing in steps of 1 to a hash seed value that makes it happen every time, include it in your report. - Do not include the created code in your report. Given proper input, it's redundant, and it's not likely that I will look at it without the ability to change the Python or Nuitka source and re-run it. - Do not send screenshots of text, that is bad and lazy. Instead, capture text outputs from the console. *************************** Unsupported functionality *************************** The ``co_code`` attribute of code objects ========================================= The code objects are empty for native compiled functions. There is no bytecode with Nuitka's compiled function objects, so there is no way to provide it. PDB === There is no tracing of compiled functions to attach a debugger to. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/README.rst0000644000175100017520000024036515063223176020443 0ustar00nuitka-buildslavenuitka-buildslave.. image:: https://img.shields.io/pypi/pyversions/Nuitka.svg :target: https://pypi.org/project/Nuitka .. image:: https://badge.fury.io/py/Nuitka.svg :target: https://pypi.org/project/Nuitka .. image:: https://img.shields.io/badge/Contributor%20Covenant-v1.4%20adopted-ff69b4.svg :target: CODE_OF_CONDUCT.md #################### Nuitka User Manual #################### This document is the recommended first read when you start using **Nuitka**. On this page, you will learn more about **Nuitka** fundamentals, such as license type, use cases, requirements, and credits. .. contents:: Table of Contents :depth: 1 :local: :class: page-toc Nuitka is **the** Python compiler. It is written in Python. It is a seamless replacement or extension to the Python interpreter and compiles **every** construct that Python 2 (2.6, 2.7) and Python 3 (3.4 - 3.13) have, when itself run with that Python version. It then executes uncompiled code and compiled code together in an extremely compatible manner. You can use all Python library modules and all extension modules freely. Nuitka translates the Python modules into a C level program that then uses ``libpython`` and static C files of its own to execute in the same way as CPython does. All optimization is aimed at avoiding overhead, where it's unnecessary. None is aimed at removing compatibility, although slight improvements will occasionally be done, where not every bug of standard Python is emulated, e.g. more complete error messages are given, but there is a full compatibility mode to disable even that. ************** Requirements ************** To ensure smooth operation of **Nuitka**, make sure to follow system requirements, that include the following components: .. contents:: :depth: 1 :local: C Compiler ========== You need a C compiler with support for C11 or alternatively a C++ compiler for C++03 [#]_. Currently, this means, you need to use one of these compilers: - The MinGW64 C11 compiler, on Windows, must be based on gcc 11.2 or higher. It will be *automatically* downloaded if no usable C compiler is found, which is the recommended way of installing it, as Nuitka will also upgrade it for you. - Visual Studio 2022 or higher on Windows [#]_. English language pack for best results (Nuitka filters away garbage outputs, but only for English language). It will be used by default if installed. - On all other platforms, the ``gcc`` compiler of at least version 5.1, and below that the ``g++`` compiler of at least version 4.4 as an alternative. - The ``clang`` compiler on macOS X and most FreeBSD architectures. - On Windows, the ``clang-cl`` compiler on Windows can be used if provided by the Visual Studio installer. .. [#] Support for this C11 is given with gcc 5.x or higher or any clang version. The older MSVC compilers don't do it yet. But as a workaround, with Python 3.10 or older, the C++03 language standard is significantly overlapping with C11, it is then used instead. .. [#] Download for free from https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx (the community editions work just fine). The latest version is recommended, but not required. On the other hand, there is no need to except to support pre-Windows 10 versions, and they might work for you, but support of these configurations is only available to commercial users. Python ====== **Python 2** (2.6, 2.7) and **Python 3** (3.4 — 3.13) are supported. If at any moment, there is a stable Python release that is not in this list, rest assured it is being worked on and will be added. .. important:: For Python 3.4 and *only* that version, we need other Python version as a *compile time* dependency. Nuitka itself is fully compatible with all listed versions, but Scons as an internally used tool is not. For these versions, you *need* a Python2 or Python 3.5 or higher installed as well, but only during the compile time. That is for use with Scons (which orchestrates the C compilation), which does not support the same Python versions as Nuitka. In addition, on Windows, Python2 cannot be used because ``clcache`` does not work with it, there a Python 3.5 or higher needs to be installed. Nuitka finds these needed Python versions (e.g. on Windows via registry) and you shouldn't notice it as long as they are installed. Increasingly, other functionality is available when another Python has a certain package installed. For example, onefile compression will work for a Python 2.x when another Python is found that has the ``zstandard`` package installed. .. admonition:: Moving binaries to other machines The created binaries can be made executable independent of the Python installation, with ``--standalone`` and ``--onefile`` options. .. admonition:: Binary filename suffix The created binaries have an ``.exe`` suffix on Windows. On other platforms they have no suffix for standalone mode, or ``.bin`` suffix, that you are free to remove or change, or specify with the ``-o`` option. The suffix for acceleration mode is added just to be sure that the original script name and the binary name do not ever collide, so we can safely overwrite the binary without destroying the original source file. .. admonition:: It **has to** be CPython, Anaconda Python, or Homebrew You need the standard Python implementation, called "CPython", to execute Nuitka because it is closely tied to implementation details of it. .. admonition:: It **cannot be** from the Windows app store It is known that Windows app store Python definitely does not work, it's checked against. .. admonition:: It **cannot be** pyenv on macOS It is known that macOS "pyenv" does **not** work. Use Homebrew instead for self compiled Python installations. But note that standalone mode will be worse on these platforms and not be as backward compatible with older macOS versions. Operating System ================ Supported Operating Systems: Linux, FreeBSD, NetBSD, macOS, and Windows (32 bits/64 bits/ARM). Others will work as well. The portability is expected to be generally good, but the e.g. Nuitka's internal Scons usage may have to be adapted or need flags passed. Make sure to match Python and C compiler architecture, or else you will get cryptic error messages. Architecture ============ Supported Architectures are x86, x86_64 (amd64), and arm, likely many, many more. Other architectures are expected to also work, out of the box, as Nuitka is generally not using any hardware specifics. These are just the ones tested and known to be good. Feedback is welcome. Generally, the architectures that Debian supports can be considered good and tested, too. ******* Usage ******* Command Line ============ The recommended way of executing Nuitka is `` -m nuitka`` to be absolutely certain which Python interpreter you are using, so it is easier to match with what Nuitka has. The next best way of executing Nuitka bare that is from a source checkout or archive, with no environment variable changes, most noteworthy, you do not have to mess with ``PYTHONPATH`` at all for Nuitka. You just execute the ``nuitka`` and ``nuitka-run`` scripts directly without any changes to the environment. You may want to add the ``bin`` directory to your ``PATH`` for your convenience, but that step is optional. Moreover, if you want to execute with the right interpreter, in that case, be sure to execute `` bin/nuitka`` and be good. .. admonition:: Pick the right Interpreter If you encounter a ``SyntaxError`` you absolutely most certainly have picked the wrong interpreter for the program you are compiling. Nuitka has a ``--help`` option to output what it can do: .. code:: bash nuitka --help The ``nuitka-run`` command is the same as ``nuitka``, but with a different default. It tries to compile *and* directly execute a Python script: .. code:: bash nuitka-run --help This option that is different is ``--run``, and passing on arguments after the first non-option to the created binary, so it is somewhat more similar to what plain ``python`` will do. Installation ============ For most systems, there will be packages on the `download page `__ of Nuitka. But you can also install it from source code as described above, but also like any other Python program it can be installed via the normal ``python setup.py install`` routine. Notice for integration with GitHub workflows there is this `Nuitka-Action `__ that you should use that makes it really easy to integrate. You ought to start with a local compilation though, but this will be easiest for cross platform compilation with Nuitka. License ======= Nuitka is licensed under the Apache License, Version 2.0; you may not use it except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ************************************* Tutorial Setup and build on Windows ************************************* This is basic steps if you have nothing installed, of course if you have any of the parts, just skip it. Setup ===== Install Python -------------- - Download and install Python from https://www.python.org/downloads/windows - Select one of ``Windows x86-64 web-based installer`` (64 bits Python, recommended) or ``x86 executable`` (32 bits Python) installer. - Verify it's working using command ``python --version``. Install Nuitka -------------- - ``python -m pip install nuitka`` - Verify using command ``python -m nuitka --version`` Write some code and test ======================== Create a folder for the Python code ----------------------------------- - ``mkdir`` HelloWorld - make a python file named **hello.py** .. code:: python def talk(message): return "Talk " + message def main(): print(talk("Hello World")) if __name__ == "__main__": main() Test your program ----------------- Do as you normally would. Running Nuitka on code that works incorrectly is not easier to debug. .. code:: bash python hello.py ---- Build it using -------------- .. code:: bash python -m nuitka hello.py .. note:: This will prompt you to download a C caching tool (to speed up repeated compilation of generated C code) and a MinGW64 based C compiler, unless you have a suitable MSVC installed. Say ``yes`` to both those questions. Run it ------ Execute the ``hello.exe`` created near ``hello.py``. Distribute ---------- To distribute, build with ``--standalone`` option, which will not output a single executable, but a whole folder. Copy the resulting ``hello.dist`` folder to the other machine and run it. You may also try ``--onefile`` which does create a single file, but make sure that the mere standalone is working, before turning to it, as it will make the debugging only harder, e.g. in case of missing data files. *********** Use Cases *********** Use Case 1 — Program compilation with all modules embedded ============================================================ If you want to compile a whole program recursively, and not only the single file that is the main program, do it like this: .. code:: bash python -m nuitka --follow-imports program.py .. note:: There are more fine-grained controls than ``--follow-imports`` available. Consider the output of ``nuitka --help``. Including fewer modules into the compilation, but instead using normal Python for it, will make it faster to compile. In case you have a source directory with dynamically loaded files, i.e. one which cannot be found by recursing after normal import statements via the ``PYTHONPATH`` (which would be the recommended way), you can always require that a given directory shall also be included in the executable: .. code:: bash python -m nuitka --follow-imports --include-plugin-directory=plugin_dir program.py .. note:: If you don't do any dynamic imports, simply setting your ``PYTHONPATH`` at compilation time is what you should do. Use ``--include-plugin-directory`` only if you make ``__import__()`` calls that Nuitka cannot predict, and that come from a directory, for everything from your Python installation, use ``--include-module`` or ``--include-package``. .. note:: The resulting filename will be ``program.exe`` on Windows, ``program.bin`` on other platforms, but ``--output-filename`` allows changing that. .. note:: The resulting binary still depends on CPython and used C extension modules being installed. If you want to be able to copy it to another machine, use ``--standalone`` and copy the created ``program.dist`` directory and execute the ``program.exe`` (Windows) or ``program`` (other platforms) put inside. Use Case 2 — Extension Module compilation =========================================== If you want to compile a single extension module, all you have to do is this: .. code:: bash python -m nuitka --mode=module some_module.py The resulting file ``some_module.so`` can then be used instead of ``some_module.py``. .. important:: The filename of the produced extension module must not be changed as Python insists on a module name derived function as an entry point, in this case ``PyInit_some_module`` and renaming the file will not change that. Match the filename of the source code to what the binary name should be. .. note:: If both the extension module and the source code of it are in the same directory, the extension module is loaded. Changes to the source code only have effect once you recompile. .. note:: The option ``--follow-import-to`` works as well, but the included modules will only become importable *after* you imported the ``some_module`` name. If these kinds of imports are invisible to Nuitka, e.g. dynamically created, you can use ``--include-module`` or ``--include-package`` in that case, but for static imports it should not be needed. .. note:: An extension module can never include other extension modules. You will have to create a wheel for this to be doable. .. note:: The resulting extension module can only be loaded into a CPython of the same version and doesn't include other extension modules. Use Case 3 — Package compilation ================================== If you need to compile a whole package and embed all modules, that is also feasible, use Nuitka like this: .. code:: bash python -m nuitka --mode=module some_package --include-package=some_package .. note:: The inclusion of the package contents needs to be provided manually; otherwise, the package is mostly empty. You can be more specific if you like, and only include part of it, or exclude part of it, e.g. with ``--nofollow-import-to='*.tests'`` you would not include the unused test part of your code. .. note:: Data files located inside the package will not be embedded by this process, you need to copy them yourself with this approach. Alternatively, you can use the `file embedding of Nuitka commercial `__. Use Case 4 — Program Distribution =================================== For distribution to other systems, there is the standalone mode, which produces a folder for which you can specify ``--standalone``. .. code:: bash python -m nuitka --standalone program.py Following all imports is default in this mode. You can selectively exclude modules by specifically saying ``--nofollow-import-to``, but then an ``ImportError`` will be raised when import of it is attempted at program run time. This may cause different behavior, but it may also improve your compile time if done wisely. For data files to be included, use the option ``--include-data-files==`` where the source is a file system path, but the target has to be specified relative. For the standalone mode, you can also copy them manually, but this can do extra checks, and for the onefile mode, there is no manual copying possible. To copy some or all file in a directory, use the option ``--include-data-files=/etc/*.txt=etc/`` where you get to specify shell patterns for the files, and a subdirectory where to put them, indicated by the trailing slash. .. important:: Nuitka does not consider data files code, do not include DLLs, or Python files as data files, and expect them to work, they will not, unless you really know what you are doing. In the following, non-code data files are all files, not matching on of these criterions. +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | Suffix | Rationale | Solution | +============+========================================================================================+========================================================================================================+ | ``.py`` | Nuitka trims even the stdlib modules to be included. If it doesn't see Python code, | Use ``--include-module`` on them instead | | | there is no dependencies analyzed, and as a result it will just not work. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyc`` | Same as ``.py``. | Use ``--include-module`` on them from their source code instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyo`` | Same as ``.pyc``. | Use ``--include-module`` on them from their source code instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyw`` | Same as ``.py``. | For including multiple programs, use multiple ``--main`` arguments instead. | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyi`` | These are ignored, because they are code-like and not needed at run time. For the | Raise an issue if 3rd part software needs it. | | | ``lazy`` package that actually would depend on them, we made a compile time solution | | | | that removes the need. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.pyx`` | These are ignored, because they are Cython source code not used at run time | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.dll`` | These are ignored, since they **usually** are not data files. For the cases where 3rd | Create Nuitka Package configuration for those, with ``dll`` section for the package that uses them. | | | party packages do actually used them as data, e.g. ``.NET`` packages, we solve that in | For rare cases, data-files section with special configuration might be the correct thing to do. | | | package configuration for it. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.dylib`` | These are ignored, since they macOS extension modules or DLLs. | Need to add configuration with ``dll`` section or ``depends`` that are missing | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.so`` | These are ignored, since they Linux, BSD, etc. extension modules or DLLs. | Need to add configuration with ``dll`` section or ``depends`` that are missing | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.exe`` | The are binaries to Windows. | You can add Nuitka Package configuration to include those as DLLs and mark them as ``executable: yes`` | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ | ``.bin`` | The are binaries to non-Windows, otherwise same as ``.exe``. | | +------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ Also folders are ignored, these are ``site-packages``, ``dist-packages`` and ``vendor-packages`` which would otherwise include a full virtualenv, which is never a good thing to happen. And the ``__pycache__`` folder is also always ignored. On non-MacOS the file ``.DS_Store`` is ignored too, and ``py.typed`` folders have only meaning to IDEs, and are ignored like ``.pyi`` files . To copy a whole folder with all non-code files, you can use ``--include-data-dir=/path/to/images=images`` which will place those in the destination, and if you want to use the ``--noinclude-data-files`` option to remove them. Code files are as detailed above DLLs, executables, Python files, etc. and will be ignored. For those you can use the ``--include-data-files=/binaries/*.exe=binary/`` form to force them, but that is not recommended and known to cause issues at run-time. For package data, there is a better way, namely using ``--include-package-data``, which detects all non-code data files of packages automatically and copies them over. It even accepts patterns in a shell style. It spares you the need to find the package directory yourself and should be preferred whenever available. Functionally it's very similar to ``--include-data-dir`` but it has the benefit to locate the correct folder for you. With data files, you are largely on your own. Nuitka keeps track of ones that are needed by popular packages, but it might be incomplete. Raise issues if you encounter something in these. Even better, raise PRs with enhancements to the Nuitka package configuration. We want 3rd party software to just work out of the box. When that is working, you can use the onefile mode if you so desire. .. code:: bash python -m nuitka --onefile program.py This will create a single binary, that extracts itself on the target, before running the program. But notice, that accessing files relative to your program is impacted, make sure to read the section `Onefile: Finding files`_ as well. .. code:: bash # Create a binary that unpacks into a temporary folder python -m nuitka --onefile program.py .. note:: There are more platform-specific options, e.g. related to icons, splash screen, and version information, consider the ``--help`` output for the details of these and check the section Tweaks_. For the unpacking, by default a unique user temporary path one is used, and then deleted, however this default ``--onefile-tempdir-spec="{TEMP}/onefile_{PID}_{TIME}"`` can be overridden with a path specification, then using a cached path, avoiding repeated unpacking, e.g. with ``--onefile-tempdir-spec="{CACHE_DIR}/{COMPANY}/{PRODUCT}/{VERSION}"`` which uses version information, and user-specific cache directory. .. note:: Using cached paths will be relevant, e.g. when Windows Firewall comes into play because otherwise, the binary will be a different one to it each time it is run. Currently, these expanded tokens are available: +----------------+-----------------------------------------------------------+---------------------------------------+ | Token | What this Expands to | Example | +================+===========================================================+=======================================+ | {TEMP} | User temporary file directory | C:\\Users\\...\\AppData\\Locals\\Temp | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PID} | Process ID | 2772 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {TIME} | Time in seconds since the epoch. | 1299852985 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM} | Full program run-time filename of executable. | C:\\SomeWhere\\YourOnefile.exe | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM_BASE} | No-suffix of run-time filename of executable. | C:\\SomeWhere\\YourOnefile | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PROGRAM_DIR} | Containing directory of executable. | C:\\SomeWhere | +----------------+-----------------------------------------------------------+---------------------------------------+ | {CACHE_DIR} | Cache directory for the user. | C:\\Users\\SomeBody\\AppData\\Local | +----------------+-----------------------------------------------------------+---------------------------------------+ | {COMPANY} | Value given as ``--company-name`` | YourCompanyName | +----------------+-----------------------------------------------------------+---------------------------------------+ | {PRODUCT} | Value given as ``--product-name`` | YourProductName | +----------------+-----------------------------------------------------------+---------------------------------------+ | {VERSION} | Combination of ``--file-version`` & ``--product-version`` | 3.0.0.0-1.0.0.0 | +----------------+-----------------------------------------------------------+---------------------------------------+ | {HOME} | Home directory for the user. | /home/somebody | +----------------+-----------------------------------------------------------+---------------------------------------+ | {NONE} | When provided for file outputs, ``None`` is used | see notice below | +----------------+-----------------------------------------------------------+---------------------------------------+ | {NULL} | When provided for file outputs, ``os.devnull`` is used | see notice below | +----------------+-----------------------------------------------------------+---------------------------------------+ .. important:: It is your responsibility to make the path provided unique, on Windows a running program will be locked, and while using a fixed folder name is possible, it can cause locking issues in that case, where the program gets restarted. Usually, you need to use ``{TIME}`` or at least ``{PID}`` to make a path unique, and this is mainly intended for use cases, where e.g. you want things to reside in a place you choose or abide your naming conventions. .. important:: For disabling output and stderr with ``--force-stdout-spec`` and ``--force-stderr-spec`` the values ``{NONE}`` and ``{NULL}`` achieve it, but with different effect. With ``{NONE}``, the corresponding handle becomes ``None``. As a result, e.g. ``sys.stdout`` will be ``None``, which is different from ``{NULL}`` where it will be backed by a file pointing to ``os.devnull``, i.e. you can write to it. With ``{NONE}``, you may e.g. get ``RuntimeError: lost sys.stdout`` in case it does get used; with ``{NULL}`` that never happens. However, some libraries handle this as input for their logging mechanism, and on Windows this is how you are compatible with ``pythonw.exe`` which is behaving like ``{NONE}``. Use Case 5 — Setuptools Wheels ================================ If you have a ``setup.py``, ``setup.cfg`` or ``pyproject.toml`` driven creation of wheels for your software in place, putting Nuitka to use is extremely easy. Let's start with the most common ``setuptools`` approach, you can, having Nuitka installed of course, simply execute the target ``bdist_nuitka`` rather than the ``bdist_wheel``. It takes all the options and allows you to specify some more, that are specific to Nuitka. .. code:: python # For setup.py if you don't use other build systems: setup( # Data files are to be handled by setuptools and not Nuitka package_data={"some_package": ["some_file.txt"]}, ..., # This is to pass Nuitka options. command_options={ 'nuitka': { # boolean option, e.g. if you cared for C compilation commands '--show-scons': True, # options without value, e.g. enforce using Clang '--clang': None, # options with single values, e.g. enable a plugin of Nuitka '--enable-plugin': "pyside2", # options with several values, e.g. avoid including modules '--nofollow-import-to' : ["*.tests", "*.distutils"], }, }, ) # For setup.py with other build systems: # The tuple nature of the arguments is required by the dark nature of # "setuptools" and plugins to it, that insist on full compatibility, # e.g. "setuptools_rust" setup( # Data files are to be handled by setuptools and not Nuitka package_data={"some_package": ["some_file.txt"]}, ..., # This is to pass Nuitka options. ..., command_options={ 'nuitka': { # boolean option, e.g. if you cared for C compilation commands '--show-scons': ("setup.py", True), # options without value, e.g. enforce using Clang '--clang': ("setup.py", None), # options with single values, e.g. enable a plugin of Nuitka '--enable-plugin': ("setup.py", "pyside2"), # options with several values, e.g. avoid including modules '--nofollow-import-to' : ("setup.py", ["*.tests", "*.distutils"]), } }, ) If for some reason, you cannot or do not want to change the target, you can add this to your ``setup.py``. .. code:: python # For setup.py setup( ..., build_with_nuitka=True ) .. note:: To temporarily disable the compilation, you could the remove above line, or edit the value to ``False`` by or take its value from an environment variable if you so choose, e.g. ``bool(os.getenv("USE_NUITKA", "True"))``. This is up to you. Or you could put it in your ``setup.cfg`` .. code:: toml [metadata] build_with_nuitka = true And last, but not least, Nuitka also supports the new ``build`` meta, so when you have a ``pyproject.toml`` already, simple replace or add this value: .. code:: toml [build-system] requires = ["setuptools>=42", "wheel", "nuitka", "toml"] build-backend = "nuitka.distutils.Build" # Data files are to be handled by setuptools and not Nuitka [tool.setuptools.package-data] some_package = ['data_file.txt'] [tool.nuitka] # These are not recommended, but they make it obvious to have effect. # boolean option, e.g. if you cared for C compilation commands, leading # dashes are omitted show-scons = true # options with single values, e.g. enable a plugin of Nuitka enable-plugin = "pyside2" # options with several values, e.g. avoid including modules, accepts # list argument. nofollow-import-to = ["*.tests", "*.distutils"] .. note:: For the ``nuitka`` requirement above absolute paths like ``C:\Users\...\Nuitka`` will also work on Linux, use an absolute path with *two* leading slashes, e.g. ``//home/.../Nuitka``. .. note:: Whatever approach you take, data files in these wheels are not handled by Nuitka at all, but by setuptools. You can, however, use the data file embedding of Nuitka commercial. In that case, you actually would embed the files inside the extension module itself, and not as a file in the wheel. Use Case 6 — Multidist ======================== If you have multiple programs, that each should be executable, in the past you had to compile multiple times, and deploy all of these. With standalone mode, this, of course, meant that you were fairly wasteful, as sharing the folders could be done, but wasn't really supported by Nuitka. Enter ``Multidist``. There is an option ``--main`` that replaces or adds to the positional argument given. And it can be given multiple times. When given multiple times, Nuitka will create a binary that contains the code of all the programs given, but sharing modules used in them. They therefore do not have to be distributed multiple times. Let's call the basename of the main path, and entry point. The names of these must, of course, be different. Then the created binary can execute either entry point, and will react to what ``sys.argv[0]`` appears to it. So if executed in the right way (with something like ``subprocess`` or OS API you can control this name), or by renaming or copying the binary, or symlinking to it, you can then achieve the miracle. This allows to combine very different programs into one. .. note:: This feature is still experimental. Use with care and report your findings should you encounter anything that is undesirable behavior This mode works with standalone, onefile, and mere acceleration. It does not work with module mode. Use Case 7 — Building with GitHub Workflows ============================================= For integration with GitHub workflows there is this `Nuitka-Action `__ that you should use that makes it really easy to integrate. You ought to start with a local compilation though, but this will be easiest for cross platform compilation with Nuitka. This is an example workflow that builds on all 3 OSes .. code:: yaml jobs: build: strategy: matrix: os: [macos-latest, ubuntu-latest, windows-latest] runs-on: ${{ matrix.os }} steps: - name: Check-out repository uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: '3.10' cache: 'pip' cache-dependency-path: | **/requirements*.txt - name: Install your Dependencies run: | pip install -r requirements.txt -r requirements-dev.txt - name: Build Executable with Nuitka uses: Nuitka/Nuitka-Action@main with: nuitka-version: main script-name: your_main_program.py # many more Nuitka options available, see action doc, but it's best # to use nuitka-project: options in your code, so e.g. you can make # a difference for macOS and create an app bundle there. mode: onefile - name: Upload Artifacts uses: actions/upload-artifact@v4 with: name: ${{ runner.os }} Build path: | # match what's created for the 3 OSes build/*.exe build/*.bin build/*.app/**/* If you app is a GUI, e.g. ``your_main_program.py`` should contain these comments as explained in `Nuitka Options in the code`_ since on macOS this should then be a bundle. .. code:: python # Compilation mode, standalone everywhere, except on macOS there app bundle # nuitka-project-if: {OS} in ("Windows", "Linux", "FreeBSD"): # nuitka-project: --onefile # nuitka-project-if: {OS} == "Darwin": # nuitka-project: --standalone # nuitka-project: --macos-create-app-bundle # .. note:: This is best expression with ``nuitka-project: --mode=app`` which encapsulates these options. ******** Tweaks ******** Icons ===== For good looks, you may specify icons. On Windows, you can provide an icon file, a template executable, or a PNG file. All of these will work and may even be combined: .. code:: bash # These create binaries with icons on Windows python -m nuitka --onefile --windows-icon-from-ico=your-icon.png program.py python -m nuitka --onefile --windows-icon-from-ico=your-icon.ico program.py python -m nuitka --onefile --windows-icon-template-exe=your-icon.ico program.py # These create application bundles with icons on macOS python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.png program.py python -m nuitka --macos-create-app-bundle --macos-app-icon=your-icon.icns program.py .. note:: With Nuitka, you do not have to create platform-specific icons, but instead it will convert e.g. PNG, but also other formats on the fly during the build. MacOS Entitlements ================== Entitlements for an macOS application bundle can be added with the option, ``--macos-app-protected-resource``, all values are listed on `this page from Apple `__ An example value would be ``--macos-app-protected-resource=NSMicrophoneUsageDescription:Microphone access`` for requesting access to a Microphone. After the colon, the descriptive text is to be given. .. note:: Beware that in the likely case of using spaces in the description part, you need to quote it for your shell to get through to Nuitka and not be interpreted as Nuitka arguments. Console Window ============== On Windows, the console is not opened by programs unless you say so. Nuitka defaults to not show it, you can force it by using ``--console=force`` though, then the program will open a new terminal Window when its executed. Splash screen ============= Splash screens are useful when program startup is slow. Onefile startup itself is not slow, but your program may be, and you cannot really know how fast the computer used will be, so it might be a good idea to have them. Luckily, with Nuitka, they are easy to add for Windows. For the splash screen, you need to specify it as a PNG file, and then make sure to disable the splash screen when your program is ready, e.g. has completed the imports, prepared the window, connected to the database, and wants the splash screen to go away. Here we are using the project syntax to combine the code with the creation, compile this: .. code:: python # nuitka-project: --mode=onefile # nuitka-project: --mode=onefile-windows-splash-screen-image={MAIN_DIRECTORY}/Splash-Screen.png # Whatever this is, obviously print("Delaying startup by 10s...") import time, tempfile, os time.sleep(10) # Use this code to signal the splash screen removal. if "NUITKA_ONEFILE_PARENT" in os.environ: splash_filename = os.path.join( tempfile.gettempdir(), "onefile_%d_splash_feedback.tmp" % int(os.environ["NUITKA_ONEFILE_PARENT"]), ) if os.path.exists(splash_filename): os.unlink(splash_filename) print("Done... splash should be gone.") ... # Rest of your program goes here. Reports ======= For analysis of your program and Nuitka packaging, there is the `Compilation Report`_ available. You can also make custom reports by providing your template, with a few of them built-in to Nuitka. These reports carry all the detail information, e.g. when a module was attempted to be imported, but not found, you can see where that happens. For bug reporting, it is very much recommended to provide the report. Version Information =================== You can attach copyright and trademark information, company name, product name, and so on to your compilation. This is then used in version information for the created binary on Windows, or application bundle on macOS. If you find something that is lacking, please let us know. ****************** Typical Problems ****************** Deployment Mode =============== By default, Nuitka compiles without ``--deployment`` which leaves a set of safe guards and helpers on, that are aimed at debugging wrong uses of Nuitka. This is a new feature, and implements a bunch of protections and helpers, that are documented here. Fork bombs (self-execution) --------------------------- So after compilation, ``sys.executable`` is the compiled binary. In case of packages like ``multiprocessing``, ``joblib``, or ``loky`` what these typically do is to expect to run from a full ``python`` with ``sys.executable`` and then to be able to use its options like ``-c command`` or ``-m module_name`` and then be able to launch other code temporarily or permanently as a service daemon. With Nuitka however, this executes your program again, and puts these arguments, in ``sys.argv`` where you maybe ignore them, and then you fork yourself again to launch the helper daemons. Sometimes this ends up spawning CPU count processes that spawn CPU count processes that... this is called a fork bomb, and with almost all systems, that freezes them easily to death. That is why e.g. this happens with default Nuitka: .. code:: ./hello.dist/hello.bin -l fooL -m fooM -n fooN -o fooO -p Error, the program tried to call itself with '-m' argument. Disable with '--no-deployment-flag=self-execution'. Your program may well have its own command line parsing, and not use an unsupported package that does attempt to re-execute. In this case, you need at *compile time* to use ``--no-deployment-flag=self-execution`` which disables this specific guard. Misleading Messages ------------------- Some packages output what they think is helpful information about what the reason of a failed import might mean. With compiled programs there are very often just plain wrong. We try and repair those in non-deployment mode. Here is an example, where we change a message that asks to pip install (which is not the issue) to point the user to the include command that makes an ``imageio`` plugin work. .. code:: yaml - module-name: 'imageio.core.imopen' anti-bloat: - replacements_plain: '`pip install imageio[{config.install_name}]` to install it': '`--include-module={config.module_name}` with Nuitka to include it' 'err_type = ImportError': 'err_type = RuntimeError' when: 'not deployment' And much more ------------- The deployment mode is relatively new and has constantly more features added, e.g. something for ``FileNotFoundError`` should be coming soon. Disabling All ------------- All these helpers can of course be disabled at once with ``--deployment`` but keep in mind that for debugging, you may want to re-enable it. You might want to use Nuitka Project options and an environment variable to make this conditional. Should you disable them all? We believe, disabling should only happen selectively, but with PyPI upgrades, your code changes, all of these issues can sneak back in. The space saving of deployment mode is currently negligible, so attempt to not do it, but review what exists, and if you know that it cannot affect you, or if it does, you will not need it. Some of the future ones, will clearly be geared at beginner level usage. Windows Virus scanners ====================== Binaries compiled on Windows with default settings of Nuitka and no further actions taken might be recognized by some AV vendors as malware. This is avoidable, but only in Nuitka commercial there is actual support and instructions for how to do it, seeing this as a typical commercial only need. https://nuitka.net/doc/commercial.html Linux Standalone ================ For Linux standalone it is pretty difficult to build a binary that works on other Linux versions. This is mainly because on Linux, much software is built specifically targeted to concrete DLLs. Things like glibc used, are then encoded into the binary built, and it will not run with an older glibc, just to give one critical example. The solution is to build on the oldest OS that you want to see supported. Picking that and setting it up can be tedious, so can be login, and keeping it secure, as it's something you put your source code on. To aid that, Nuitka commercial has container based builds, that you can use. This uses dedicated optimized Python builds, targets CentOS 7 and supports even newest Pythons and very old OSes that way using recent C compiler chains all turn key solution. The effort needs to be compensated to support Nuitka development for Linux, there you need to purchase it https://nuitka.net/doc/commercial.html but even a sponsor license will be cheaper than doing it yourself. Program crashes system (fork bombs) =================================== A fork bomb is a program that starts itself over and over. This can easily happen, since ``sys.executable`` for compiled programs is not a Python interpreter, and packages that try to do multiprocessing in a better way, often relaunch themselves through this, and Nuitka needs and does have handling for these with known packages. However, you may encounter a situation where the detection of this fails. See deployment option above that is needed to disable this protection. When this fork bomb happens easily all memory, all CPU of the system that is available to the user is being used, and even the most powerful build system will go down in flames sometimes needing a hard reboot. For fork bombs, we can use ``--experimental=debug-self-forking`` and see what it does, and we have a trick, that prevents fork bombs from having any actual success in their bombing. Put this at the start of your program. .. code:: python import os, sys if "NUITKA_LAUNCH_TOKEN" not in os.environ: sys.exit("Error, need launch token or else fork bomb suspected.") else: del os.environ["NUITKA_LAUNCH_TOKEN"] Actually Nuitka is trying to get ahold of them without the deployment option already, finding "-c" and "-m" options, but it may not be perfect or not work well with a package (anymore). Memory issues and compiler bugs =============================== In some cases, the C compilers will crash saying they cannot allocate memory or that some input was truncated, or similar error messages, clearly from it. These are example error messages, that are a sure sign of too low memory, there is no end to them. .. code:: # gcc fatal error: error writing to -: Invalid argument Killed signal terminated program # MSVC fatal error C1002: compiler is out of heap space in pass 2 fatal error C1001: Internal compiler error There are several options you can explore here. Ask Nuitka to use less memory ----------------------------- There is a dedicated option ``--low-memory`` which influences decisions of Nuitka, such that it avoids high usage of memory during compilation at the cost of increased compile time. Avoid 32 bit C compiler/assembler memory limits ----------------------------------------------- Do not use a 32 bit compiler, but a 64 bit one. If you are using Python with 32 bits on Windows, you most definitely ought to use MSVC as the C compiler, and not MinGW64. The MSVC is a cross-compiler, and can use more memory than gcc on that platform. If you are not on Windows, that is not an option, of course. Also, using the 64 bit Python will work. Use a minimal virtualenv ------------------------ When you compile from a living installation, that may well have many optional dependencies of your software installed. Some software will then have imports on these, and Nuitka will compile them as well. Not only may these be just the troublemakers, they also require more memory, so get rid of that. Of course, you do have to check that your program has all the needed dependencies before you attempt to compile, or else the compiled program will equally not run. Use LTO compilation or not -------------------------- With ``--lto=yes`` or ``--lto=no`` you can switch the C compilation to only produce bytecode, and not assembler code and machine code directly, but make a whole program optimization at the end. This will change the memory usage pretty dramatically, and if your error is coming from the assembler, using LTO will most definitely avoid that. Switch the C compiler to clang ------------------------------ People have reported that programs that fail to compile with gcc due to its bugs or memory usage work fine with clang on Linux. On Windows, this could still be an option, but it needs to be implemented first for the automatic downloaded gcc, that would contain it. Since MSVC is known to be more memory effective anyway, you should go there, and if you want to use Clang, there is support for the one contained in MSVC. Add a larger swap file to your embedded Linux --------------------------------------------- On systems with not enough RAM, you need to use swap space. Running out of it is possibly a cause, and adding more swap space, or one at all, might solve the issue, but beware that it will make things extremely slow when the compilers swap back and forth, so consider the next tip first or on top of it. Limit the amount of compilation jobs ------------------------------------ With the ``--jobs`` option of Nuitka, it will not start many C compiler instances at once, each competing for the scarce resource of RAM. By picking a value of one, only one C compiler instance will be running, and on an 8 core system, that reduces the amount of memory by factor 8, so that's a natural choice right there. Dynamic ``sys.path`` ==================== If your script modifies ``sys.path``, e.g. inserts directories with source code relative to it, Nuitka will not be able to see those. However, if you set the ``PYTHONPATH`` to the resulting value, it will be able to compile it and find the used modules from these paths as well. Manual Python File Loading ========================== A very frequent pattern with private code is that it scans plugin directories of some kind, and e.g. uses ``os.listdir``, then considers Python filenames, and then opens a file and does ``exec`` on them. This approach works for Python code, but for compiled code, you should use this much cleaner approach, that works for pure Python code and is a lot less vulnerable. .. code:: python # Using a package name, to locate the plugins. This is also a sane # way to organize them into a directory. scan_path = scan_package.__path__ for item in pkgutil.iter_modules(scan_path): importlib.import_module(scan_package.__name__ + "." + item.name) # You may want to do it recursively, but we don't do this here in # this example. If you'd like to, handle that in this kind of branch. if item.ispkg: ... Missing data files in standalone ================================ If your program fails to find data file, it can cause all kinds of different behavior, e.g. a package might complain it is not the right version because a ``VERSION`` file check defaulted to an unknown. The absence of icon files or help texts, may raise strange errors. Often the error paths for files not being present are even buggy and will reveal programming errors like unbound local variables. Please look carefully at these exceptions, keeping in mind that this can be the cause. If your program works without standalone, chances are data files might be the cause. The most common error indicating file absence is of course an uncaught ``FileNotFoundError`` with a filename. You should figure out what package is missing files and then use ``--include-package-data`` (preferably), or ``--include-data-dir``/``--include-data-files`` to include them. Missing DLLs/EXEs in standalone =============================== Nuitka has plugins that deal with copying DLLs. For NumPy, SciPy, Tkinter, etc. These need special treatment to be able to run on other systems. Manually copying them is not enough and will give strange errors. Sometimes newer version of packages, esp. NumPy can be unsupported. In this case, you will have to raise an issue, and use the older one. If you want to manually add a DLL or an EXE because it is your project only, you will have to use user Yaml files describing where they can be found. This is described in detail with examples in the `Nuitka Package Configuration `__ page. Dependency creep in standalone ============================== Some packages are a single import, but to Nuitka mean that more than a thousand packages (literally) are to be included. The prime example of Pandas, which does want to plug and use just about everything you can imagine. Multiple frameworks for syntax highlighting everything imaginable take time. Nuitka will have to learn effective caching to deal with this in the future. Presently, you will have to deal with huge compilation times for these. A major weapon in fighting dependency creep should be applied, namely the ``anti-bloat`` plugin, which offers interesting abilities, that can be put to use and block unneeded imports, giving an error for where they occur. Use it e.g. like this ``--noinclude-pytest-mode=nofollow --noinclude-setuptools-mode=nofollow`` and e.g. also ``--noinclude-custom-mode=setuptools:error`` to get the compiler to error out for a specific package. Make sure to check its help output. It can take for each module of your choice, e.g. forcing also that e.g. ``PyQt5`` is considered uninstalled for standalone mode. It's also driven by a configuration file, ``anti-bloat.yml`` that you can contribute to, removing typical bloat from packages. Please don't hesitate to enhance it and make PRs towards Nuitka with it. Standalone: Finding files ========================= The standard code that normally works, also works, you should refer to ``os.path.dirname(__file__)`` or use all the packages like ``pkgutil``, ``pkg_resources``, ``importlib.resources`` to locate data files near the standalone binary. .. important:: What you should **not** do, is use the current directory ``os.getcwd``, or assume that this is the script directory, e.g. with paths like ``data/``. If you did that, it was never good code. Links, to a program, launching from another directory, etc. will all fail in bad ways. Do not make assumptions about the directory your program is started from. In case you mean to refer to the location of the ``.dist`` folder for files that are to reside near the binary, there is ``__compiled__.containing_dir`` that also abstracts all differences with ``--macos-create-app-bundle`` and the ``.app`` folder a having more nested structure. .. code:: python # This will find a file *near* your app or dist folder try: open(os.path.join(__compiled__.containing_dir, "user-provided-file.txt")) except NameError: open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) Onefile: Finding files ====================== There is a difference between ``sys.argv[0]`` and ``__file__`` of the main module for the onefile mode, that is caused by using a bootstrap to a temporary location. The first one will be the original executable path, whereas the second one will be the temporary or permanent path the bootstrap executable unpacks to. Data files will be in the later location, your original environment files will be in the former location. Given 2 files, one which you expect to be near your executable, and one which you expect to be inside the onefile binary, access them like this. .. code:: python # This will find a file *near* your onefile.exe open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) # This will find a file *inside* your onefile.exe open(os.path.join(os.path.dirname(__file__), "user-provided-file.txt")) # This will find a file *near* your onefile binary and work for standalone too try: open(os.path.join(__compiled__.containing_dir, "user-provided-file.txt")) except NameError: open(os.path.join(os.path.dirname(sys.argv[0]), "user-provided-file.txt")) .. note:: When the program is launched from the executable, the original ``sys.argv[0]`` from the invocation command line will not be preserved, it will be made an absolute path. For advanced use cases where one needs access to the original ``sys.argv[0]``, it may be found at ``__compiled__.original_argv0``. The field will read back as ``None`` if the program is not launched from the onefile executable, thus not having gone through the onefile bootstrap stage; the original ``sys.argv[0]`` would be preserved as well in this case. .. code:: python # Suppose the onefile binary is placed at /opt/abc/bin/foo, and it was # symlinked to /usr/local/bin/bar, and invoked as `bar ...`: assert sys.argv[0] == "/usr/local/bin/bar" assert __compiled__.original_argv0 == "bar" # If the onefile tempdir is overridden and the program is invoked # directly from the unpacked location, sys.argv[0] would not be touched. # # Suppose the onefile tempdir is /home/xx/.cache/abc/0.1.2, and the # foo.bin executable inside is symlinked to /usr/local/bin/baz, and # invoked as `baz ...`: assert sys.argv[0] == "baz" assert __compiled__.original_argv0 is None Windows Programs without console give no errors =============================================== For debugging purposes, use the options ``--force-stdout-spec`` and ``--force-stderr-spec`` with paths as documented for ``--onefile-tempdir-spec`` above. These can be relative to the program or absolute, so you can see the outputs given. Also you can run the program on a terminal prompt like ``CMD.exe`` to see its outputs. Deep copying uncompiled functions ================================= Sometimes people use this kind of code, which for packages on PyPI, we deal with by doing source code patches on the fly. If this is in your own code, here is what you can do: .. code:: python def binder(func, name): result = types.FunctionType(func.__code__, func.__globals__, name=func.__name__, argdefs=func.__defaults__, closure=func.__closure__) result = functools.update_wrapper(result, func) result.__kwdefaults__ = func.__kwdefaults__ result.__name__ = name return result Compiled functions cannot be used to create uncompiled ones from, so the above code will not work. However, there is a dedicated ``clone`` method, that is specific to them, so use this instead. .. code:: python def binder(func, name): try: result = func.clone() except AttributeError: result = types.FunctionType(func.__code__, func.__globals__, name=func.__name__, argdefs=func.__defaults__, closure=func.__closure__) result = functools.update_wrapper(result, func) result.__kwdefaults__ = func.__kwdefaults__ result.__name__ = name return result Modules: Extension modules are not executable directly ====================================================== A package can be compiled with Nuitka, no problem, but when it comes to executing it, ``python -m compiled_module`` is not going to work and give the error ``No code object available for AssertsTest`` because the compiled module is not source code, and Python will not just load it. The closest would be ``python -c "import compile_module"`` and you might have to call the main function yourself. To support this, the CPython ``runpy`` and/or ``ExtensionFileLoader`` would need improving such that Nuitka could supply its compiled module object for Python to use. ****** Tips ****** Nuitka Options in the code ========================== One clean way of providing options to Nuitka, that you will always use for your program, is to put them into the main file you compile. There is even support for conditional options, and options using pre-defined variables, this is an example: .. code:: python # Compilation mode, support OS-specific options # nuitka-project-if: {OS} in ("Windows", "Linux", "Darwin", "FreeBSD"): # nuitka-project: --mode=app # nuitka-project-else: # nuitka-project: --mode=standalone # The PySide2 plugin covers qt-plugins # nuitka-project: --enable-plugin=pyside2 # nuitka-project: --include-qt-plugins=qml The comments must be at the start of lines, and indentation inside of them is to be used, to end a conditional block, much like in Python. There are currently no other keywords than the used ones demonstrated above. You can put arbitrary Python expressions there, and if you wanted to e.g. access a version information of a package, you could simply use ``__import__("module_name").__version__`` if that would be required to e.g. enable or disable certain Nuitka settings. The only thing Nuitka does that makes this not Python expressions, is expanding ``{variable}`` for a pre-defined set of variables: Table with supported variables: +------------------+--------------------------------+------------------------------------------+ | Variable | What this Expands to | Example | +==================+================================+==========================================+ | {OS} | Name of the OS used | Linux, Windows, Darwin, FreeBSD, OpenBSD | +------------------+--------------------------------+------------------------------------------+ | {Version} | Version of Nuitka | e.g. (1, 6, 0) | +------------------+--------------------------------+------------------------------------------+ | {Commercial} | Version of Nuitka Commercial | e.g. (2, 1, 0) | +------------------+--------------------------------+------------------------------------------+ | {Arch} | Architecture used | x86_64, arm64, etc. | +------------------+--------------------------------+------------------------------------------+ | {MAIN_DIRECTORY} | Directory of the compiled file | some_dir/maybe_relative | +------------------+--------------------------------+------------------------------------------+ | {Flavor} | Variant of Python | e.g. Debian Python, Anaconda Python | +------------------+--------------------------------+------------------------------------------+ The use of ``{MAIN_DIRECTORY}`` is recommended when you want to specify a filename relative to the main script, e.g. for use in data file options or user package configuration yaml files, .. code:: python # nuitka-project: --include-data-files={MAIN_DIRECTORY}/my_icon.png=my_icon.png # nuitka-project: --user-package-configuration-file={MAIN_DIRECTORY}/user.nuitka-package.config.yml Python command line flags ========================= For passing things like ``-O`` or ``-S`` to Python, to your compiled program, there is a command line option name ``--python-flag=`` which makes Nuitka emulate these options. The most important ones are supported, more can certainly be added. Caching compilation results =========================== The C compiler, when invoked with the same input files, will take a long time and much CPU to compile over and over. Make sure you are having ``ccache`` installed and configured when using gcc (even on Windows). It will make repeated compilations much faster, even if things are not yet perfect, i.e. changes to the program can cause many C files to change, requiring a new compilation instead of using the cached result. On Windows, with gcc, Nuitka supports using ``ccache.exe``, which it will offer to download from an official source and install it automatically. This is the recommended way of using it on Windows, as other versions may cause issues e.g. hanging. Nuitka will pick up ``ccache`` if it's found in system ``PATH``, and it will also be possible to provide if by setting ``NUITKA_CCACHE_BINARY`` to the full path of the binary, this is for use in CI systems where environments might be non-standard. For the MSVC compilers and ClangCL setups, using the ``clcache`` is automatic and included in Nuitka. On macOS and Intel, there is an automatic download of a ``ccache`` binary from our site, for arm64 arches, it's recommended to use this setup, which installs Homebrew and ccache in there. Nuitka picks that one up automatically if it on that kind of machine. You need and should not use Homebrew with Nuitka otherwise, it's not the best for standalone deployments, but we can take ``ccache`` from there. .. code:: bash export HOMEBREW_INSTALL_FROM_API=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" eval $(/opt/homebrew/bin/brew shellenv) brew install ccache Control where Caches live ========================= The storage for cache results of all kinds, downloads, cached compilation results from C and Nuitka, is done in a platform dependent directory as determined by the ``appdirs`` package. However, you can override it with setting the environment variable ``NUITKA_CACHE_DIR`` to a base directory. This is for use in environments where the home directory is not persisted, but other paths are. There is also per cache control of these caches, here is a table of environment variables that you can set before starting the compilation, to make Nuitka store some of these caches in an entirely separate space. +------------------+-----------------------------------+----------------------------------------+ | Cache name | Environment Variable | Data Put there | +==================+===================================+========================================+ | downloads | NUITKA_CACHE_DIR_DOWNLOADS | Downloads made, e.g. dependency walker | +------------------+-----------------------------------+----------------------------------------+ | ccache | NUITKA_CACHE_DIR_CCACHE | Object files created by gcc | +------------------+-----------------------------------+----------------------------------------+ | clcache | NUITKA_CACHE_DIR_CLCACHE | Object files created by MSVC | +------------------+-----------------------------------+----------------------------------------+ | bytecode | NUITKA_CACHE_DIR_BYTECODE | Bytecode of demoted modules | +------------------+-----------------------------------+----------------------------------------+ | dll-dependencies | NUITKA_CACHE_DIR_DLL_DEPENDENCIES | DLL dependencies | +------------------+-----------------------------------+----------------------------------------+ Runners ======= Avoid running the ``nuitka`` binary, doing ``python -m nuitka`` will make a 100% sure you are using what you think you are. Using the wrong Python will make it give you ``SyntaxError`` for good code or ``ImportError`` for installed modules. That is happening, when you run Nuitka with Python2 on Python3 code and vice versa. By explicitly calling the same Python interpreter binary, you avoid that issue entirely. Fastest C Compilers =================== The fastest binaries of ``pystone.exe`` on Windows with 64 bits Python proved to be significantly faster with MinGW64, roughly 20% better score. So it is recommended for use over MSVC. Using ``clang-cl.exe`` of Clang7 was faster than MSVC, but still significantly slower than MinGW64, and it will be harder to use, so it is not recommended. On Linux, for ``pystone.bin``, the binary produced by ``clang6`` was faster than ``gcc-6.3``, but not by a significant margin. Since gcc is more often already installed, that is recommended to use for now. Differences in C compilation times have not yet been examined. Unexpected Slowdowns ==================== Using the Python DLL, like standard CPython does, can lead to unexpected slowdowns, e.g. in uncompiled code that works with Unicode strings. This is because calling to the DLL rather than residing in the DLL causes overhead, and this even happens to the DLL with itself, being slower, than a Python all contained in one binary. So if feasible, aim at static linking, which is currently only possible with Anaconda Python on non-Windows, Debian Python2, self compiled Pythons (do not activate ``--enable-shared``, not needed), and installs created with ``pyenv``. .. note:: On Anaconda, you may need to execute ``conda install libpython-static`` Standalone executables and dependencies ======================================= The process of making standalone executables for Windows traditionally involves using an external dependency walker to copy necessary libraries along with the compiled executables to the distribution folder. There are plenty of ways to find that something is missing. Do not manually copy things into the folder, esp. not DLLs, as that's not going to work. Instead, make bug reports to get these handled by Nuitka properly. Windows errors with resources ============================= On Windows, the Windows Defender tool and the Windows Indexing Service both scan the freshly created binaries, while Nuitka wants to work with it, e.g. adding more resources, and then preventing operations randomly due to holding locks. Make sure to exclude your compilation stage from these services. Windows standalone program redistribution ========================================= Whether compiling with MingW or MSVC, the standalone programs have external dependencies to Visual C Runtime libraries. Nuitka tries to ship those dependent DLLs by copying them from your system. Beginning with Microsoft Windows 10, Microsoft ships ``ucrt.dll`` (Universal C Runtime libraries) which handles calls to ``api-ms-crt-*.dll``. With earlier Windows platforms (and wine/ReactOS), you should consider installing Visual C runtime libraries before executing a Nuitka standalone compiled program. Depending on the used C compiler, you'll need the following redist versions on the target machines. However, notice that compilation using the 14.3 based version is always recommended, working and best supported, unless you want to target Windows 7. +------------------+-------------+----------+ | Visual C version | Redist Year | CPython | +==================+=============+==========+ | 14.3 | 2022 | 3.11 | +------------------+-------------+----------+ | 14.2 | 2019 | 3.5-3.10 | +------------------+-------------+----------+ | 14.1 | 2017 | 3.5-3.8 | +------------------+-------------+----------+ | 14.0 | 2015 | 3.5-3.8 | +------------------+-------------+----------+ | 10.0 | 2010 | 3.4 | +------------------+-------------+----------+ | 9.0 | 2008 | 2.6, 2.7 | +------------------+-------------+----------+ When using MingGW64 as downloaded by Nuitka, you'll need the following redist versions: +----------------------------+-------------+---------------------+ | MingGW64 version | Redist Year | CPython | +============================+=============+=====================+ | WinLibs automatic download | 2015 | 2.6, 2.7, 3.4- 3.11 | +----------------------------+-------------+---------------------+ Once the corresponding runtime libraries are installed on the target system, you may remove all ``api-ms-crt-*.dll`` files from your Nuitka compiled dist folder. Detecting Nuitka at run time ============================ Nuitka does *not* ``sys.frozen`` unlike other tools because it usually triggers inferior code for no reason. For Nuitka, we have the module attribute ``__compiled__`` to test if a specific module was compiled, and the function attribute ``__compiled__`` to test if a specific function was compiled. Providing extra Options to Nuitka C compilation =============================================== Nuitka will apply values from the environment variables ``CCFLAGS``, ``LDFLAGS`` during the compilation on top of what it determines to be necessary. Beware, of course, that this is only useful if you know what you are doing, so should this pose issues, raise them only with perfect information. Producing a 32 bit binary on a 64 bit Windows system ==================================================== Nuitka will automatically target the architecture of the Python you are using. If this is 64 bit, it will create a 64 bit binary, if it is 32 bit, it will create a 32 bit binary. You have the option to select the bits when you download the Python. In the output of ``python -m nuitka --version`` there is a line for the architecture. It's ``Arch: x86_64`` for 64 bits, and just ``Arch: x86`` for 32 bits. The C compiler will be picked to match that more or less automatically. If you specify it explicitly, and it mismatches, you will get a warning about the mismatch and informed that your compiler choice was rejected. ******************** Compilation Report ******************** When you use ``--report=compilation-report.xml`` Nuitka will create an XML file with detailed information about the compilation and packaging process. This is growing in completeness with every release and exposes module usage attempts, timings of the compilation, plugin influences, data file paths, DLLs, and reasons why things are included or not. At this time, the report contains absolute paths in some places, with your private information. The goal is to make this blended out by default because we also want to become able to compare compilation reports from different setups, e.g. with updated packages, and see the changes to Nuitka. The report is, however, recommended for your bug reporting. Also, another form is available, where the report is free form and according to a Jinja2 template of yours, and one that is included in Nuitka. The same information as used to produce the XML file is accessible. However, right now, this is not yet documented, but we plan to add a table with the data. For a reader of the source code that is familiar with Jinja2, however, it will be easy to do it now already. If you have a template, you can use it like this ``--report-template=your_template.rst.j2:your_report.rst`` and of course, the usage of restructured text, is only an example. You can use Markdown, your own XML, or whatever you see fit. Nuitka will just expand the template with the compilation report data. Currently, the following reports are included in Nuitka. You just use the name as a filename, and Nuitka will pick that one instead. +---------------+--------------+--------------------------------------------------------+ | Report Name | Status | Purpose | +===============+==============+========================================================+ | LicenseReport | experimental | Distributions used in a compilation with license texts | +---------------+--------------+--------------------------------------------------------+ .. note:: The community can and should contribute more report types and help enhancing the existing ones for good looks. ************* Performance ************* This chapter gives an overview, of what to currently expect in terms of performance from Nuitka. It's a work in progress and is updated as we go. The current focus for performance measurements is Python 2.7, but 3.x is going to follow later. pystone results =============== The results are the top value from this kind of output, running pystone 1000 times and taking the minimal value. The idea is that the fastest run is most meaningful, and eliminates usage spikes. .. code:: bash echo "Uncompiled Python2" for i in {1..100}; do BENCH=1 python2 tests/benchmarks/pystone.py ; done | sort -rn | head -n 1 python2 -m nuitka --lto=yes --pgo-c tests/benchmarks/pystone.py echo "Compiled Python2" for i in {1..100}; do BENCH=1 ./pystone.bin ; done | sort -n | head -rn 1 PYTHON3=python3.10 # Using a 100 gives semi-reliable values already, 1000 for best accuracy. RUNS=1000 $PYTHON3 -m nuitka --lto=yes --pgo-c --static-libpython=yes tests/benchmarks/pystone3.py echo "Uncompiled $PYTHON3" for i in $(seq 1 $RUNS); do BENCH=1 $PYTHON3 tests/benchmarks/pystone3.py ; done | sort -rn | head -n 1 echo "Compiled $PYTHON3" for i in $(seq 1 $RUNS); do BENCH=1 ./pystone3.bin ; done | sort -rn | head -n 1 +-------------------+-------------------+----------------------+---------------------+ | Python | Uncompiled | Compiled LTO | Compiled PGO | +===================+===================+======================+=====================+ | Debian Python 2.7 | 137497.87 (1.000) | 460995.20 (3.353) | 503681.91 (3.663) | +-------------------+-------------------+----------------------+---------------------+ | Nuitka Python 2.7 | 144074.78 (1.048) | 479271.51 (3.486) | 511247.44 (3.718) | +-------------------+-------------------+----------------------+---------------------+ Report issues or bugs ===================== Should you encounter any issues, bugs, or ideas, please visit the `Nuitka bug tracker `__ and report them. Best practices for reporting bugs: - Please always include the following information in your report, for the underlying Python version. You can easily copy&paste this into your report. It does contain more information than you think. Do not write something manually. You may always add, of course, .. code:: bash python -m nuitka --version - Try to make your example minimal. That is, try to remove code that does not contribute to the issue as much as possible. Ideally, come up with a small reproducing program that illustrates the issue, using ``print`` with different results when the program runs compiled or native. - If the problem occurs spuriously (i.e. not each time), try to set the environment variable ``PYTHONHASHSEED`` to ``0``, disabling hash randomization. If that makes the problem go away, try increasing in steps of 1 to a hash seed value that makes it happen every time, include it in your report. - Do not include the created code in your report. Given proper input, it's redundant, and it's not likely that I will look at it without the ability to change the Python or Nuitka source and re-run it. - Do not send screenshots of text, that is bad and lazy. Instead, capture text outputs from the console. *************************** Unsupported functionality *************************** The ``co_code`` attribute of code objects ========================================= The code objects are empty for native compiled functions. There is no bytecode with Nuitka's compiled function objects, so there is no way to provide it. PDB === There is no tracing of compiled functions to attach a debugger to. ././@PaxHeader0000000000000000000000000000003300000000000010211 xustar0027 mtime=1758275202.384262 Nuitka-2.7.16/bin/0000700000175100017520000000000015063223202017466 5ustar00nuitka-buildslavenuitka-buildslave././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/bin/autoformat-nuitka-source0000755000175100017520000000221615063223176024411 0ustar00nuitka-buildslavenuitka-buildslave#!/usr/bin/env python3 # Copyright 2025, Kay Hayen, mailto:kay.hayen@gmail.com find license text at end of file """ Launcher for autoformat tool. """ import os import sys # Unchanged, running from checkout, use the parent directory, the nuitka # package ought to be there. sys.path.insert(0, os.path.normpath(os.path.join(os.path.dirname(__file__), ".."))) # isort:start from nuitka.tools.quality.auto_format.__main__ import main main() # Part of "Nuitka", an optimizing Python compiler that is compatible and # integrates with CPython, but also works on its own. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/bin/check-nuitka-with-pylint0000755000175100017520000000221515063223176024274 0ustar00nuitka-buildslavenuitka-buildslave#!/usr/bin/env python3 # Copyright 2025, Kay Hayen, mailto:kay.hayen@gmail.com find license text at end of file """ Launcher for pylint checker tool. """ import os import sys # Unchanged, running from checkout, use the parent directory, the nuitka # package ought to be there. sys.path.insert(0, os.path.normpath(os.path.join(os.path.dirname(__file__), ".."))) # isort:start from nuitka.tools.quality.pylint.__main__ import main main() # Part of "Nuitka", an optimizing Python compiler that is compatible and # integrates with CPython, but also works on its own. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/bin/compare_with_cpython0000755000175100017520000000231615063223176023667 0ustar00nuitka-buildslavenuitka-buildslave#!/usr/bin/env python # Copyright 2025, Kay Hayen, mailto:kay.hayen@gmail.com find license text at end of file """ Launcher for output comparison tool. """ import os import sys # Unchanged, running from checkout, use the parent directory, the nuitka # package ought to be there. sys.path.insert(0, os.path.normpath(os.path.join(os.path.dirname(__file__), ".."))) os.environ.setdefault("PYTHON", sys.executable) # isort:start from nuitka.tools.testing.compare_with_cpython.__main__ import main main() # Part of "Nuitka", an optimizing Python compiler that is compatible and # integrates with CPython, but also works on its own. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/bin/compare_with_xml0000755000175100017520000000604115063223176023002 0ustar00nuitka-buildslavenuitka-buildslave#!/usr/bin/env python # Copyright 2025, Kay Hayen, mailto:kay.hayen@gmail.com find license text at end of file """ Tool to compare XML outputs of two Nuitka versions. """ import os import sys # Unchanged, running from checkout, use the parent directory, the nuitka # package ought to be there. sys.path.insert(0, os.path.normpath(os.path.join(os.path.dirname(__file__), ".."))) # isort:start import difflib from nuitka.tools.testing.Common import my_print from nuitka.utils.Execution import executeProcess nuitka1 = sys.argv[1] nuitka2 = sys.argv[2] filename = sys.argv[3] my_print( """\ Comparing output of '{filename}' using '{nuitka1}' <-> '{nuitka2}' ...""".format( filename=filename, nuitka1=nuitka1, nuitka2=nuitka2 ) ) extra_options = os.getenv("NUITKA_EXTRA_OPTIONS", "") nuitka1_cmd = "{nuitka1} --xml {filename}".format(nuitka1=nuitka1, filename=filename) nuitka2_cmd = "{nuitka2} --xml {filename}".format(nuitka2=nuitka2, filename=filename) stdout_nuitka1, stderr_nuitka1, exit_nuitka1 = executeProcess(nuitka1_cmd, shell=True) stdout_nuitka2, stderr_nuitka2, exit_nuitka2 = executeProcess(nuitka2_cmd, shell=True) def makeDiffable(output): result = [] for line in output.split(b"\n"): line = str(line) result.append(line) return result def compareOutput(kind, out1, out2): diff = difflib.unified_diff( makeDiffable(out1), makeDiffable(out2), "{program} ({detail})".format(program="nuitka1 " + filename, detail=kind), "{program} ({detail})".format(program="nuitka2 " + filename, detail=kind), None, None, n=3, ) result = list(diff) if result: for line in result: my_print(line, end="\n" if not line.startswith("---") else "") return 1 else: return 0 exit_code_stdout = compareOutput("stdout", stdout_nuitka1, stdout_nuitka2) exit_code_return = exit_nuitka1 != exit_nuitka2 if exit_code_return: my_print( """\ Exit codes {exit_nuitka1:d} ({nuitka1}) != {exit_nuitka2:d} ({nuitka2})""".format( exit_nuitka1=exit_nuitka1, nuitka1=nuitka1, exit_nuitka2=exit_nuitka2, nuitka2=nuitka2, ) ) exit_code = exit_code_stdout or exit_code_return if exit_code: sys.exit("Error, outputs differed.") my_print("OK, same outputs.") # Part of "Nuitka", an optimizing Python compiler that is compatible and # integrates with CPython, but also works on its own. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/bin/measure-construct-performance0000755000175100017520000000225215063223176025423 0ustar00nuitka-buildslavenuitka-buildslave#!/usr/bin/env python # Copyright 2025, Kay Hayen, mailto:kay.hayen@gmail.com find license text at end of file """ Launcher for construct performance tool. """ import os import sys # Unchanged, running from checkout, use the parent directory, the nuitka # package ought to be there. sys.path.insert(0, os.path.normpath(os.path.join(os.path.dirname(__file__), ".."))) # isort:start from nuitka.tools.testing.measure_construct_performance.__main__ import main main() # Part of "Nuitka", an optimizing Python compiler that is compatible and # integrates with CPython, but also works on its own. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/bin/nuitka0000755000175100017520000000326415063223176020740 0ustar00nuitka-buildslavenuitka-buildslave#!/usr/bin/env python # Copyright 2025, Kay Hayen, mailto:kay.hayen@gmail.com find license text at end of file """ Launcher for Nuitka the compiler itself. """ # Import as little as possible initially, because we might be re-executing # soon. import os import sys # Unchanged, running from checkout, use the parent directory, the nuitka # package ought to be there. sys.path.insert(0, os.path.normpath(os.path.join(os.path.dirname(__file__), ".."))) # isort:start import nuitka.__main__ # false alarm, pylint: disable=I0021,no-name-in-module # Remove the nuitka package directory again, it might contain other stuff that we # do not want added automatically. del sys.path[0] # The bin folder of the runner can't be that helpful, but got added automatically, # so attempt to remove it. sys.path = [ path_element for path_element in sys.path if os.path.dirname(os.path.abspath(__file__)) != path_element ] # Now execute Nuitka in a clean environment. nuitka.__main__.main() # Part of "Nuitka", an optimizing Python compiler that is compatible and # integrates with CPython, but also works on its own. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/bin/nuitka-run0000755000175100017520000000326415063223176021542 0ustar00nuitka-buildslavenuitka-buildslave#!/usr/bin/env python # Copyright 2025, Kay Hayen, mailto:kay.hayen@gmail.com find license text at end of file """ Launcher for Nuitka the compiler itself. """ # Import as little as possible initially, because we might be re-executing # soon. import os import sys # Unchanged, running from checkout, use the parent directory, the nuitka # package ought to be there. sys.path.insert(0, os.path.normpath(os.path.join(os.path.dirname(__file__), ".."))) # isort:start import nuitka.__main__ # false alarm, pylint: disable=I0021,no-name-in-module # Remove the nuitka package directory again, it might contain other stuff that we # do not want added automatically. del sys.path[0] # The bin folder of the runner can't be that helpful, but got added automatically, # so attempt to remove it. sys.path = [ path_element for path_element in sys.path if os.path.dirname(os.path.abspath(__file__)) != path_element ] # Now execute Nuitka in a clean environment. nuitka.__main__.main() # Part of "Nuitka", an optimizing Python compiler that is compatible and # integrates with CPython, but also works on its own. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ././@PaxHeader0000000000000000000000000000003300000000000010211 xustar0027 mtime=1758275202.384262 Nuitka-2.7.16/doc/0000700000175100017520000000000015063223202017463 5ustar00nuitka-buildslavenuitka-buildslave././@PaxHeader0000000000000000000000000000003300000000000010211 xustar0027 mtime=1758275202.384262 Nuitka-2.7.16/doc/Logo/0000700000175100017520000000000015063223202020363 5ustar00nuitka-buildslavenuitka-buildslave././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/doc/Logo/Nuitka-Logo-Horizontal.svg0000644000175100017520000000340515063223176025412 0ustar00nuitka-buildslavenuitka-buildslaveNuitka././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/doc/Logo/Nuitka-Logo-Symbol.svg0000644000175100017520000000302115063223176024520 0ustar00nuitka-buildslavenuitka-buildslave././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/doc/Logo/Nuitka-Logo-Vertical.svg0000644000175100017520000000340115063223176025026 0ustar00nuitka-buildslavenuitka-buildslaveNuitka././@PaxHeader0000000000000000000000000000003300000000000010211 xustar0027 mtime=1758275202.384262 Nuitka-2.7.16/doc/images/0000700000175100017520000000000015063223202020730 5ustar00nuitka-buildslavenuitka-buildslave././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/doc/images/Nuitka-Logo-Horizontal.png0000644000175100017520000001664115063223176025752 0ustar00nuitka-buildslavenuitka-buildslavePNG  IHDRaxugAMA asRGB cHRMz&u0`:pQ< pHYsHHFk>bKGDCIDATxyUǿ3%$@A E@QكK؅dM6 @(N@>A$1d'$S={k|?nuWߪ[:EQz8`* hfk8 XW'Т](rIAɼiO`?"EQŅ,A5O3-}t^JCR@Q ܡǁEHz3g(9}b}g $ iylkD:٧nEKcrnmsm?K7tqc:`Nccs#GlKLb8](y66{쳀E /bbƈ|۰:  ٬L,͛1 nFx6k֬)T⭷z^jJCr6j;w/WGIt"'ZE^ ̙3KM#ue 3fOKc1DHtu0=x=Hq1V,-p.;s]?EQHR#?nm'H4M>=Xp 0i<z"0ȶf:4$6Յ{C`7}뭷4EKk]ef&,7669+[Z95p.;+^ ˴D"qlX&'G :BT|B/\}p'Ic̗`n@[߲݌3&zO:1 8x  \,o](҈غ΢[nNR" $M: 0{)`Htt-oY'S<5GAEJ$7Dt9n-߈)XJ茁H^iE8bqt02[GE7Qb.,Ĝ^nWx7f0f/;n͆~CAQE-,p8̅As/áq|]o|Vk)*[E~G6e<`ezoC"2"V1эYލɧ^KRD\E ">'&~06"2سkz4$0n#  A؀[ؾpw68DZC"U'E?FPy{]g4探{_1}4d!bak>bH;G(Jh:n'psN"ǨbtM75kFIt!n\`1B_;]ڞJi["K2p?wVr(Frvo} 1xP$ݤIOIYqTJ~ |9b1{ sld[XLx1؄)1) ebܗc=NO~xX<]-]Sʐn@^nG8#}$WQ`H4[hnX^"`-w-܈Dl=Y{ж*\.*=|H.B8+JTֳ-#޿p@yYO~xX`uk⽌''"9|yH ѱX "DNE',.(=Z۶Ly_V?A"$xd@C޴aP:nŻjfzPfhBS0r6t$͋ =5$$5)Jdg[K0Ɉ_k=-ˑ,X!5 x, ItDuCg6toI&b2x۽qˌɍ^(fdm׏ !'w<{N,dwoKe8X@kpu;MY<}lPϟT"Np@KR|GwRqNpeEUey.`?~'ۺ;Y.xuMpVI\䊹{zS8S]`~E%c`@M9h\ pUEw`FOtbwЧHLjÄ(gWH*?&#k͈#OYwa'U )K.^Sl,۳kӞn)c0ez6StVK7C|ڜ ܆R|@flDBljH,A>mv)ǁ'股)O%hCkcc6ѯx8-qVӂ>y9]es*K)dTE7Osj; ~TRֻ[D|[L/[ sPQݿv |28 ŀZWx#&m-Kqe,ߌ/54pCH@(r'~,Dkwlc"uͼגZtYCsKF\tM/g-mFVP9z$+<.>rh3<q_KRvl}ܔ`N-4S K]VWQj}H?:WrĞ3\ nQͼ߷agn`hKcvn>[!iqV0)`p2tge{c,n潾ٱQlЖ$G{nY oisMQ0I:bR#tdD7w=aؼ_җTBE7|8\u+JIh>aiw+ԣDTE7s2zü:M<5kM93MErYyvz޾4ՒVnTs>mӡ(V6O1ޘn 3Xv(Q9yD"1?^¿5H7EG[8qF {G À!@d}{Afޒ޿ sLYߏbHq^Tt.>3WR|ס o/47ՀYMeWCqXا40 OWU l*݌(6G*tr>W8Y ŝ=;/| I(1O>qȬ<Ǜ4R&#ShBBR'Fڲ\5+8ge}:#vJeyv9erXd5tMY{5^#KkJ ><ݥ(C†Z{1v]ʐ"޺>Hf? 3 z e9e$71SQ-W}ڴ"Xjw)J#iV{pN+8J">zwd-`U5TeD"kr3v魋cx q)024xC%%][z"oEFn;ldj]uԊ)(]%2@2Q8Z)%~.JsF䘯>:0$/j=O/[u}n[ڌCzð2b2 [Idy Ȭ+ ka$++q]%R<6cBcU:$d&Ay?{*<1eNt2_9IѰn&Fδx#߁-mFa//u>Z$`~Y{7 Dм[DOt@Ջq6Ds(hy?*| i|NHr3NV{?9a_j"ڙwl'ODSWsp?>\0sG[.o9{ )#pSㆬK6c[&dBg<4+he UUS$%dz:j[qZU;Jh^dߧ@>2Xpø 1Q8ɩ=]SUtcbUZCﴴ@QqhjVywo4U`Oݐ4HXCt]p35*t@(J xim: zŚAc5ܸ_qsأD"AHƭLփ,v'tK;dEͬAu { [lw"98#|έ%S"T?'j$Y /f]\CV:W޹ o"p]{'ŦBجjǶθ7-(f)¥0OZC{`oKǖg,^'K7+FPU7LٙO\8mQYc KFڨm~G3y% }o)=)ہ7,z4Eyx]Ekkh.$FxcJ7($+f"z8ֻI `i{nkzr)-%3صb ]q7'>&8X' ^.7HE;z3Lqo;|f)d]$)[:]tbc42,Cd < 0X8lyV0&dmj;)xB-u7A|_n{-fzVnHl=b/O!Y.iS C܏x34^ Wރjd/2-I$v~o܋ŭEk'#eY l]]&q*"ق|-pwc Q+zmos~ ;cpL`/u8}]щs + Ll)wr~tXfc n,,ummmP 1hp&pk,,?qc\KWn2 ogI1vսΛ)x¿a(ߤ1no0эǏD.71LUowS[pZޥHMk/=՜loo{ͫj,]t2 |no.2b|`%|X$- D˜s $hT/k5RTdHx >7.Ǐ_c9frDD7M|𫪭VB^Bgy5+*[{M~^AsFQqxGj;7 ?q8=Ova' ²-ݢQtXdɤ>{CMoFK+xiH% H?m $"LEoc6ֳz1zv=z1 b$$o=E‰Ǚ}]aw|WjC=ʇz}cu0Wwf蚬AD7^:;;/8qbgH߱Y˘@+Kp x{vϢ-ǽ{5{7]- dw]y7H!ZFd격Ͷf{99y'o|>0;"!`@B̲I{|e"q[P8]ޫ?$n;qo>;I2# RM2eEc:0dn5㨝sԾC\-is_ʻ1D"q>EQE$!k%tEXtdate:create2013-08-13T07:50:42+02:00Q6%tEXtdate:modify2013-08-13T07:50:42+02:00 kUEIENDB`././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/doc/images/Nuitka-Logo-Symbol.png0000644000175100017520000001054415063223176025062 0ustar00nuitka-buildslavenuitka-buildslavePNG  IHDRB,gAMA asRGB cHRMz&u0`:pQ< pHYsHHFk>bKGDCYIDATxoovvƎq(%ĀJqm!yi@ڪ{ΙA˜8v[  `5R?^dOk]1׮6==ґgy?Jڅ_mS^nGcrTznӦM$y"7ޛ#Ea9`rKBH ǟ羋q~$O``8.3"r+.//fgg_3e7[9E\ZCqfDIݞ(o<488J7ƙ8EO)h{ c2;;읝}H]QQ$ #"Ç/UJMNNiDWB!b||m䠔 _khhX`{EN2E9 1d%ƁNӼ6(/ _SSS7>iPxhjjj"byv>QSD!w1)iwcWXlEA1=p7cCyoL!sQx1SJ(bd*L!MQw (xbB0(|Ɇ& 8YAљ(6ߙ`)hC! F9 6 h~lA{ m"PH2{ FKyC E2FPHT>8rJEq41$ }3zm8\\ˍF f RVCE!(p [-6 QDq~ͷl„4ZW ad72D+򉫄0B!}K) : IsFyQL(ypE!ۖ Zž=1 -a$5ʧ9jZ_0dJ6{ÞD|9F (Bk|(|סDvާ`)UQfCE z(a7SFPi 6H&j,}(0cw2q"c Ê eI֖"X% {i0& {.P[(b?V|[4Q$\("ʌaPBҭD1(4 E Vmh 1MOD!Q#ceư0P0Sd0 "`Q$+aXA9A8SGcEũ1PNe"v X( ] (î =BY_ۃ0Dl } Va!B!K)Hu8N0_⾫+0Ew(Z;+eUPpq;8(aE&vahPv_/\R}[0k !vRDsp]\s"!"_ hA*q=GpYD (TSP7]Znh R(< Ή̱}(lhj{G1ܿϖ}J6Q1-_^VvYۯ& v-pS8*+eQO-m-q qU;M hOgY 9n{& ) cE[>}(S+.P(B`EW8\m&˧(>8nM]DacEnj?mqnȨ|ZWypp2!߶kQ\>3r~Qt?>u ^AMʾo5Ti(IђM}c-?{8ne8D~cBD񯯬x}nW`Y&T) $.x64 ʜ*߀مmU06tF/T3] z Face vO|ߘ1DmGC-c|ZsPL&Ikz [?Ls b0^<ڇwIgCMWj8Mrgᴆ\}0C﫡kznX%% _?W>M=Qߴ>2 (p{ CY;s켧Ea;ߟߘ0;)bw٣ }EU~-gM"&Jj(x^Fc3iP3SadCEoat `hR(ZR(x3Ft"V/y T6,DATL6 HBEAl'(DKe73FY#L1Qp-at2 ! k󭋢|D($J(c0c"b f |BڅHe(~Q(cD8. .c( fC9S$^tE) Q.f{q `$ckTL(&wc1ƞ/J7cJY`OXn{:nأw;xƘGܒ-(@2<2::/ngs{y4pQE}c̳~;22RL0igϞulPW , 4rK'_uՅ8ϑ6>Yꟛms?<[2Ƽ#"Si`z%tEXtdate:create2013-08-08T10:34:23+02:00q#%tEXtdate:modify2013-08-08T10:34:23+02:00,:IENDB`././@PaxHeader0000000000000000000000000000002600000000000010213 xustar0022 mtime=1758275198.0 Nuitka-2.7.16/doc/images/Nuitka-Logo-Vertical.png0000644000175100017520000002314415063223176025366 0ustar00nuitka-buildslavenuitka-buildslavePNG  IHDRU?cPgAMA asRGB cHRMz&u0`:pQ< pHYsHHFk>bKGDC%YIDATx}ygݻ^{](J)i@MI|xS @JSEhIq*%(B)iU B X'@ԪH4k@ ,sNkw>9sg>Ν;3Aj<Zv1CڝƘI=zR~Ŀo{ѷԥޒNjMױ7oڊ^}_ByIcIoc̏/aA?~|7JcID$oXәB+$g=z׺ʒ>sz])Mkkoz8*o]tEo02[J3>>s>IiA*[~kvJB}nj*k}q||[l1f Dˍ1G%]O$BMOHG@Yksbb6ǎZFޅS.j c?+ڛDRڀ?+ok]7oOF++$Z ն=C1Z;:66nF!Ru!K$=(Pۓ]V3jjLLLtKvI Zn6ʈDi$m!]&ܬ5= WO=b u}~&B-tP.c&*W; 6j|6nNF.RMZ\@M[2v r@}mPVkH5iC6sBm`PL4E6ZZձPf*9[ =AS+_kۓaL6:(m9*b%S%O\J~ZʽPi!U6nJ~*2Tg"W {8Bũm F3bU KO7.28oB4JB-2T)! '%PLʜ_ȕLM٪;jOy_aODeP R$n3KT.T2U 5W*@NuST] RdP* <>Nj^j(ԅj?'N7Sv T@mpj|- 5U H PHȵzsRd_Bm<]2 *@2T/_t!T@m RP-BL8NRZOk dP5 5) *@ U"U 5ZkS*@FB2)p[B6xBO ІtաP *@*"V8j*Ce? t5mg.je4Ml;1_۠ s?PLIǽL 5djJDBH_jtJ'S¤c.UJ~T"TQ'*?sOf.u.3io^dgf"԰$"U(iJ VTEj+BGH5sEl] ՏP6#Tsj"%?*RP-BEHJ6eB3VGBf B`BlDR6`Bצ7/q@:{GT2T*# d1Kcm㗳GuF/RR][y|ZN*kulr6]!BmP][KpCpd[ x8`J6<2x7zVt][k{<'B l DBGM?ʀ55^;Ps/TnFI髽[N6&k5m|Nϭm@Ѿ=Ȕ^jNZ"Մc3pI=vOv+OvxVr^:?PlwLiPs)T(試 B =.9mY_`{=ѣB"Tu\eݏ.1v{V B͛P*RE{fN>_tӾZ]3"UPGb57ܫ.Ps"TY*B͟Pf?X{_*BEFmY]O P(TT[-BWCF{w Զ r*R%CͳPg[#2woG BmPIT*B-PgfuBźӾU2]BeEPsonAχ>uy"UP.kMUuVP3eALPwoN[~յWOAdHBBmW4mC b^ފAԮ5㯘gp44c={uE R*P*BEQ_f:c=wME3" f~UoFۆFC[;W"P*BEQ_fm`X~uW BEH"ԨzS68`nZ[~*"TPjWim!֝UP*R͍N=>6;@z'Tɷ_?AVo͂Teص) m*dlZdyͮ8I 6EGa!d B%Q2՜3{f~|㖯k5yU B xn Xx3xp-yѮl;,>h},}ϋy\: T H5jHo uKcg TCO1<=VdP 54a$C Y6 '*B-Pk RE"EM 5BD\2U2R 5)FND7 Sa Bj)T HvcƟSBB7*=U**4KR+ 5.`B=B#Th3TC(*5>UByA w"T@U 5* HCcm ysD!zQT] aOշ[|(&K|_#Uu"Tc^$ H5)e-*4S}Nu*$#Ԣw~H D9rqIeKH! pPIT2̄ڸ^\r:~! d-%<3 5*dEهRm%{9F"ԂfٳgH ՖT*4P "qxnn[!z1+{)3%62j*jƘϒɓ'`YJ3 1c̗ꇈRMnajvv*+w]uU ={d%.2NNN~cddJkvwEB_7/kÇ?Yz+5|YtA 3Tg$]522rӁfgw}ER1UBeZ{E###? ᖪ{%4, uޒ1sssٳMB:=s1fGR,i O65Wo-U/ foIO#.uӋƾcg7p|K}$}]?aR>k׮i"ɸT}^tZ$i $U_;|׼4ř'%g!1.'D I!3b]qU h}c $L!IcnpRgk۞-iRHoUe`!鄤7§$}(i2ཝBm_Y)E_=ǃYA H:scjL\/TKϞ22FqB.(ɯ)I=>(-!$$DdET[:HI߫%KMvI"({ZGTLr뒺!sC"p-Ջ%9!KU}R[%EjHu@W#@:RBY^B O%PēJm/ H59a|U4EE?}|j !X6)靄j4"b}WJ}B H5[Z*͘fO^@"9KtTOJ%bb^@ge -hh~AH՗tc0C !UIElswh|x l^#VX/ˀI/>ş燕l١IIPq=cfZ»2sf3[B5%6SL<T}յ4>#0ߌ t2q %cP+*'IUR`E<`7(J&v0-" ;.CrKQm&;tվ(p0Av"0/bq v ^^`E4DF OLt +ў1wۨ76ZdfyxyxpH5 )P;g3splYJPl L4~U:`HϜMpXcgI׉_+xϼ5:pz3 ||QF#XS4 GH p2)>X'"d)DOB|Ѽǹ;I@ {9?H+,2ՈDQAr'X>nSH=QҠئGFzjfi^+:c2"WpI`/0|-kY;"c5MH2kD_j_ J@!53Ҥ9t6Vze$0NxdTL+r tZki _k]-ĬKߒn^EQ$|mN &LFu2;hV99LʷZ,"SQ NMvվ(xax?yf%IuOZTy%iA-~d!IU^98@$B9En1pܹy~oKRFե ϦBtc,9V dTȥ` }v+cGjs}ELBJMžr>?EZ9H\тHnפR`E@Q`$q-w˕O-WRP`E4$( TmIߩ=[ " ڈ T ٴRtF*nq)u]J)[(J{}&q$Y> NޠJQJDKHb朶A/$j?$ CW"Ļ]̊`:ziT_n'8+N$/:6%48,?~:ݐr(CփdۖLXKLnE% #rAIR uH*|:WbReM;= x'Wgt_h&gC4f\JŞ\QYC|A<=Ao@,7>*Qm-мDpO1 I8 H wke}`{t(J\we ̼B2Jz-kd=uԌqGw&HˑW͚(3Ž9HrO<ݐA|W+xƺܼ"ya%+FmFdck!E1R =) uoIdӭ6O!WrZq)2737L~*K0Mq#` p1 :a/RlZ)Q ,m/b*p':_BltvbXdS(b{w^f5\$j GZzeVd rE#r!C/ULGLV%G{ {SNt鍒Zql^8a67Cp`V$n)ɪQ+)}w:{GUQٜ3P-Y }|EG+dLI AK؂xp9.sXA݁ĉ&E'87 ~Y{镣>dy'z(-MUO0VIp55q2uFR ˃Q{!HH߰}cvPi^DRd6;2CcԌ̋Q 9ׯh9]vz:f9КaݧQZsE܌gSlH%b z-ls=r,n&׃>jc$Efu̺g+0+FF%n[fڡI,bV{A䘬=|Q);єt)ނ:Me`T:<%8 3fTAȫ^C#ǞHR5oq''eݨkm+ 4N H>%\k:'o2 k_Z{m,gȘQWL4>V]nYw|4N&8}7VfɎfqoo$sq~A20ge\ x$?Ro"z#w;bTwABA|7Oⵀo1[wͳQ98g?QZ0?^d<y)?§\8wLZ,~Jo⎞mH}QfVᵔ}{H<[`Xy:&wYϕQ]mbq= d罐o"#UH^o5nC~&/"Ǘ8$%}BrD&Yg'LE&܆IK2>MeHbVIjqi[;-* &NRoc.q}͍w+3 R2`UsHk쀜oiuYO 'ǻ{3fT"uw4"{9:.Kʠ{'e#%W,#UIZ1&vF3#lj8ylڎg8^&ˡeD" |}t඘ x9rm%?"uYa||S, `G1/w! }#|1Ck1n)Ioh7#L[