Python Execution — From Interpreters to Compilers and Packaging tools

Python Compilers

From a performance perspective: Static/AOT compilation > JIT compilation > JIT implementation > Interpreter

Static/AOT: Longer compile and build time, but better execution performance. Trades off some of Python's dynamic language advantages.

JIT compilation: A balance. Pre-compiles, so initial startup is slower and memory usage is higher.

Interpreter: Translates on-the-fly, fastest startup, easiest to debug and modify. Not suitable for CPU-intensive operations.

Tools	Type	Feature	Special
Static/AOT Compiler		Slow first, high performance later
Cython	Static/AOT Compiler	to C/C++	Mainly produces modules, static type declaration
Shed Skin	Static/AOT Compiler	to C++	Mainly produces modules
Nuitka	Static/AOT Compiler	to C	executables
Pythran	Static/AOT Compiler	Optimizes scientific computing code	Especially suitable for NumPy programs
JIT compiler
Numba	JIT Compiler	Compiles numerical computation code	can do partial AOT
JIT Implementation
PyPy	JIT Implementation	Dynamically compiles Python code	Fully compatible with CPython, usually faster
Pyston	JIT Implementation	Optimizes Python execution	CPython compatible
Interpreter		start fast, performance tradeoff
CPython	Interpreter	Runs Python on PVM note1	Standard Python implementation. Most widely used.
Stackless Python (Based on CPython)	Interpreter	Supports microthreads	Special handling for high concurrency.
Jython	Interpreter	Runs Python on JVM	can use Java library
IronPython	Interpreter	Runs Python on .NET	can use .NET library

note1

Note 1: In the Python world, VM and interpreter are often used interchangeably, but more precisely, "VM is considered part of the interpreter."

Can these tools be used in the same workflow? For example, using an interpreter but with a compiler underneath?

CPython (interpreter) can be used with Cython (compiler) to compile critical parts for improved performance.

Numba can be used in a CPython environment to provide JIT compilation for specific functions.

Ambiguity in CPython's definition

CPython is the default installed Python.

Wikipedia states

CPython can be defined as both an interpreter and a compiler as it compiles Python code into bytecode before interpreting it.

https://en.wikipedia.org/wiki/CPython

A Stack Overflow answer

CPython is the original Python implementation. It is the implementation you download from Python.org. People call it CPython to distinguish it from other, later, Python implementations, and to distinguish the implementation of the language engine from the Python programming language itself.

https://stackoverflow.com/questions/17130975/python-vs-cpython

While CPython is far from an AOT compiler, it could potentially be considered a JIT compiler?

There's still a significant difference between interpreters and JIT Compilers. The most obvious difference is that an interpreter uses a two-step process, translating to bytecode and then to machine code, rather than translating directly to final machine code.

Aspect	`CPython` as interpreter	JIT compiler
Timing	Compilation occurs before program execution, but only to bytecode	JIT compilation usually occurs during program runtime
Target	Bytecode, run on VM or interpreter	Directly produces machine-readable code
Optimization	Translates as encountered, no optimization	Yes
Dynamism	Can execute code in string form at runtime using `exec()` or `eval()`	More static analysis optimization, but more complex and memory-intensive

PyPy & Pyston's claim of CPython compatibility

This mainly means these implementations can run Python code written for CPython and produce the same results.

PyPy vs. Pyston compatibility differences:

PyPy offers high CPython compatibility and also supports both Python 2 and Python 3.

Pyston emphasizes its CPython compatibility, because it’s a fork from CPython.

JIT implementations like PyPy can sometimes approach or exceed certain JIT compilation scenarios.

Web servers
In some benchmark tests with network application frameworks (like Tornado), PyPy's performance can sometimes approach Go language implementations of similar servers.

Dynamic type heterogeneous data
- Suitable for NoSQL databases like MongoDB, Cassandra
- data in different formats

Memory-intensive operations
- In-memory databases
- Large-scale graph processing
- Image processing

Are CPU-intensive tasks more suitable for static compilation?

Yes, static compilation/AOT is generally more suitable.

For memory-intensive tasks like image processing, the choice between JIT and AOT depends on requirements. AOT is better for static, batch processing, while JIT is more suitable for user parameter adjustments or game-state calculations.

Specialized packages like TensorFlow and PyTorch often include both compilation modes.

Situation	CPU intensive	IO Intensive	Memory Intensive
Tool	Static/AOT Compilation	Interpreter	Depends, but definitely NOT Interpreter

Packaging tools

Python packaging tools fall into two main categories:

Standalone executable files: PyInstaller, cx_Freeze, py2exe, and py2app

Modules and libraries: For reuse in other projects, requiring interpreters.
1. setuptools: Suitable for small projects, creating modules for other directories to import.
1. Nuitka: Packages into bin or exe files for direct execution.
  As seen in the compiler table above, Nuitka is both a compiler and a packaging tool. It's quite suitable when you want to improve program performance and easily distribute to end users.
1. Poetry: Similar to native Python but runs in an isolated environment, like Docker.

pyproject.toml is a standard configuration file format used by many tools, but it's not absolute.

If simplicity is desired, using requirements.txt is fine.

tools	goal	need interpreter
setuptools (sdist)	Source distribution package	✅
setuptools (bdist_wheel)	Wheel file .whl	✅
PyInstaller	executable
cx_Freeze	executable
py2exe	.exe
py2app	.app
Nuitka	Compiles Python to native code
Poetry	Dependency management and packaging	✅
Flit	Simplifies packaging process	✅