Cython: a Python-to-C compiler for CPython extensions

The problem Cython solves inside CPython

Python code runs through the CPython interpreter. When a loop is hot, the interpreter overhead per operation dominates the arithmetic inside it. Cython takes a different route: it translates Python code to C or C++, and the README describes it as an optimising Python compiler that makes writing C extensions for Python as easy as Python itself. The output is a CPython extension module, so the rest of your program keeps running on the standard interpreter.

The second half of the pitch is C interop. Cython supports calling C functions and declaring C types on variables and class attributes, which the README frames as broad to fine-grained manual tuning. That is the part that separates it from a general-purpose optimiser: you can wrap an external C library and expose it to Python callers without writing the CPython C-API glue by hand. If your problem is a numerical inner loop with no C dependency, Cython is one option among several. If your problem is a vendored C library that Python needs to call, the type declarations and the generated module are the whole point.

How Cython generates C and where the types come from

The pipeline is a source-to-source compiler. Cython reads .py or .pyx files, produces C or C++ source, and that C source is then compiled by your system's C compiler into an extension module. The repository keeps the compiler itself under Cython/Compiler/, with separate modules for scanning, parsing and the visitor pass, and the pyproject.toml build configuration uses those exact files as a sanity check: the cibuildwheel test-command runs cython on Cython/Compiler/Visitor.py, Cython/Compiler/Scanning.py and Cython/Compiler/Parsing.py. Cython is written in Cython and bootstraps itself.

What makes the generated C fast is the type information. Plain Python source compiles, but every variable stays an object with reference counting and dynamic dispatch. Declaring a C type on a variable or a class attribute lets the compiler emit direct C operations instead. The README calls this manual tuning and lists it as a deliberate design position, not a missing feature. The generated C is also portable across Python versions, which the README describes as generate once, compile everywhere, and it is adapted at C compile time to the target platform and Python version. That is why the project ships wheels built with per-architecture flags rather than one generic binary.

Installing Cython and building a first module

The README gives one install command and one condition: if you already have a C compiler, run the pip command below. Without a C compiler, the README points to the installation page in the documentation, and no alternative path is described there.

pip install Cython

After that, the repository's Makefile shows how the project builds itself in place, which is the same shape a user build takes:

python3 setup.py build_ext --inplace

The Makefile also defines a target that produces the pure-Python wheel with setup.py bdist_wheel --no-cython-compile, and the pyproject.toml test-command runs cython directly on individual source files, which is the closest thing in the repository to a one-file compile. The repository ships pyximport/ at the top level, an import hook that compiles .pyx modules on import, and bin/ holds the cython_freeze script referenced in the README's comparison with Nuitka for static application linking. The documentation, not the README, is where the full quickstart lives; the README links to https://docs.cython.org/ for it.

Where Cython is the wrong tool

Cython does not remove the build step. The README's install instruction assumes a working C compiler, and the generated C has to be compiled for each target platform and Python version. That is a distribution cost, not a runtime one, but it lands on anyone shipping wheels. The project's own build configuration is evidence of how much per-platform work that involves: cibuildwheel is configured for x86_64, aarch64, i686 and armv7l on Linux, AMD64, x86 and ARM64 on Windows, with different CFLAGS for armv8-a and armv7l and CYTHON_LIMITED_API enabled for a specific list of targets. If your deployment target is not covered by a wheel, your users need a compiler.

Introspection and dynamic behaviour are the other boundary. The README lists full runtime compatibility with CPython as a Cython advantage and, in the same list, notes that mypyc has reduced Python compatibility and introspection after compilation. That comparison is about mypyc, not Cython, but it marks the axis to think about: code that inspects frames, rewrites classes at runtime or depends on exact traceback shapes is the kind of code where compiling is riskier than leaving it interpreted. If you want a faster interpreter without a build step and without shipping C, Cython is not that. The README is explicit that PyPy is a Python implementation with a JIT compiler, which is a different product category.

Cython compared with PyPy, Numba, Pythran and Nuitka

The README does the comparison itself, and the differences are structural rather than cosmetic. PyPy is a JIT-compiled Python implementation: it keeps a non-CPython runtime, and the README lists limited compatibility with CPython extensions and non-obvious performance results among its cons. Cython keeps CPython and changes your module, not your interpreter.

Numba is a JIT compiler for a subset of Python based on LLVM, mostly aimed at NumPy numerical code. Its cons in the README are limited language support, a relatively large runtime dependency on LLVM, and again non-obvious performance results. Pythran is a static Python-to-C++ compiler for a subset of the language, also numerical, and the README notes it can be used as a backend for NumPy code inside Cython, so the two are not mutually exclusive. mypyc compiles using PEP-484 type annotations, which the README says is similar in spirit to Cython's pure Python mode, but mypyc has no support for low-level optimisations and typing. Nuitka is highly language compliant and supports static application linking, but has no support for low-level optimisations and typing.

The pattern is consistent: Cython is the option that gives you manual control down to the C level and produces C you can inspect, at the cost of writing type declarations and running a build. The JIT tools trade that control for runtime adaptation.

Release cadence, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-21. Recent releases are 3.3.0 on 2026-08-22, a 3.3.0b1-3 pre-release on 2026-08-14, and 3.2.9 on 2026-07-24. The 3.3.0 line is the current stable one, with 3.2.9 as the maintenance release on the previous minor. That cadence matters for upgrade planning: a minor release can change generated code, so a project that pins Cython should pin it the same way it pins any build-time dependency.

On licensing, the README states that the original Pyrex program was licensed free of restrictions and that Cython itself is licensed under the permissive Apache License, with LICENSE.txt in the repository root. The practical implication is that generated C code is not the thing to worry about; check your own distribution obligations rather than assuming the permissive licence settles them. This is not legal advice.

Upgrade cost is dominated by the build matrix, not the Cython syntax. The pyproject.toml shows which CPython versions are skipped (cp36, cp37, cp38) and which platforms get the generic pure-Python wheel, and the Makefile lists the manylinux and musllinux images used for Linux wheels. If you vendor Cython into a build pipeline, that matrix is the surface you have to keep current.

Editorial conclusion

Adopt Cython when you need CPython extension modules, a C library wrapped for Python callers, or a hot loop compiled ahead of time with reproducible results. Do not adopt it if you want a drop-in faster interpreter: PyPy swaps the runtime, and Numba and Pythran optimise a subset of the language instead of generating C you ship. Before committing, verify that a C compiler is present on every machine that will build the package, since the README's install step only covers Cython itself, and check whether your code depends on introspection that the README says is reduced after compilation in comparable tools.

Frequently asked questions

Official sources

1. cython/cython on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases