# CPython: the reference interpreter behind Python 3.16, and when to build it yourself > CPython is the Python Software Foundation's C implementation of the language, currently developed toward 3.16.0 alpha 0. This article covers what it is, how to build it from source, and when a prebuilt kit from python.org is the better answer. **python/cpython** — Source repository of CPython, the reference implementation of the Python programming language and the interpreter most people run when they use Python. - Repository: https://github.com/python/cpython - Website: https://www.python.org - Stars: 77,357 · Forks: 37,006 - Language: Python - License: not declared - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/python-cpython ## What CPython actually is, and why the name has a C in it The repository is the Python programming language itself, not a library that adds to it. The README identifies the tree as Python version 3.16.0 alpha 0, so the main branch is a development line, not the stable interpreter most people install. The name CPython distinguishes this implementation from others: it is the implementation written in C, and it is the one the language definition is measured against. When someone says "Python 3.16" without qualification, they almost always mean this codebase. That distinction matters for a practical reason. A language is a specification; an implementation is a program that executes it. CPython is the implementation the Python Software Foundation develops, and its behaviour defines what most people experience as Python. Other implementations exist and are discussed below, but the repository you are looking at is the one that ships as the default on most systems. The audience is narrower than "Python users". The README addresses people building the interpreter: it documents configure options, PGO, LTO, the test suite and how to install multiple versions side by side. If you write Python applications, this repository is upstream of your runtime, not a dependency you add to a requirements file. ## How the build turns C sources into a python3 binary The top-level layout shows what kind of project this is. Python/ holds the interpreter core, Objects/ the object model, Modules/ the standard library extension modules written in C, Lib/ the pure-Python standard library, Parser/ and Grammar/ the syntax side, and Include/ the public headers. configure and configure.ac drive the build, with Makefile.pre.in as the template. There is no package manifest for a language runtime; the build system is the distribution mechanism. The README describes the optimized path in detail. Running configure --enable-optimizations sets default make targets that enable Profile Guided Optimization and may auto-enable Link Time Optimization on some platforms. PGO works in stages: the tree is cleaned of temporary files, an instrumented interpreter is built with profiling instructions embedded in the binary, a training workload runs to collect profile data, and only then is the real interpreter built from that information. The README is explicit that the instrumented binary is an intermediary and is not suitable for real workloads. LTO, enabled with --with-lto, lets the toolchain optimize across object file boundaries. That is a longer build for a measurably different artifact. The trade is build time and compiler requirements against runtime performance, and the README frames the result as "suitable for distribution or production installation". ## Installing CPython from source and running a first check The README gives the Unix, Linux, BSD, macOS and Cygwin sequence directly. Run it from the top level of the checkout; it installs Python as python3. ```bash ./configure make make test sudo make install ``` configure accepts many options, and the README points to ./configure --help for the full list. On macOS case-insensitive file systems and on Cygwin the executable is named python.exe; elsewhere it is python. For a debug interpreter, the README shows building in a subdirectory. This avoids mixing build artifacts with the source tree, and the README warns that it will fail if you also built at the top level, in which case you run make clean there first. ```bash mkdir debug cd debug ../configure --with-pydebug make make test ``` After the build, make test runs the interpreter's test suite. The README says you can generally ignore messages about skipped tests caused by optional features that cannot be imported. A failure, a traceback or a core dump is different: the README states that something is wrong. To investigate, re-run the specific failing test in verbose mode. ```bash make test TESTOPTS="-v test_os test_gdb" ``` The README notes that tests are prevented by default from overusing resources such as disk space and memory, and that make buildbottest enables those heavier tests. If a failure looks like a Python problem rather than an environment problem, the README directs you to the issue tracker with the relevant output. ## Where a source build is the wrong answer The README itself draws the boundary. Under "Using Python" it says installable Python kits and information about using Python are available at python.org. It does not present a source build as the way to get Python for everyday work. The build path exists for people who need something the distributed kits do not provide. There are also hard environmental limits. The README states that building a complete installation requires various additional third-party libraries depending on platform and configure options, and that not all standard library modules are buildable or usable on all platforms. It points to the Developer Guide's dependency section for the current list per Linux distribution and macOS. A missing library does not necessarily stop the build; it can silently leave a module out, which is why the skipped-test messages in make test exist. Windows is a separate path entirely. The README sends Windows builders to PCbuild/readme.txt, and Windows package builders to PC/layout/README.md. There is no ./configure step there. If your goal is a working python3 on a laptop, the configure and make route is more machinery than the task requires, and the README's own pointer to python.org says so. ## CPython against PyPy and Cython: different jobs, not better and worse The comparison people search for most is CPython versus PyPy. The difference is in the execution strategy. CPython is the C implementation whose behaviour the language is defined against, and this repository is its source. PyPy is a separate implementation built around a just-in-time compiler, which is a different way of running the same language and can produce different performance characteristics. The README of this repository does not document PyPy, so any claim about how the two compare on a specific workload has to come from measuring that workload, not from this tree. Cython is a different category again, and the name similarity misleads people. Cython is not an alternative interpreter for running ordinary Python programs. It is a tool for compiling Python-like code, typically with type annotations, into C extension modules. You use it alongside an interpreter rather than instead of one, and in practice that interpreter is usually CPython. The practical rule: if you want to run Python, CPython is the default and this repository is its upstream. If you want to change how the interpreter itself behaves, this is the only one of the three where you would be editing the runtime. If you want to speed up a specific numeric routine by compiling it, that is Cython's territory. ## Maintenance, versions and what the licence file does and does not say The README carries a copyright line for the Python Software Foundation dated 2001 and states that further copyright and licence information appears at the end of the file. The repository has a top-level LICENSE file. The metadata supplied for this repository does not record a licence identifier, so the accurate statement is that the licence terms live in LICENSE and in the README's closing section, and anyone redistributing a build should read them there rather than rely on a label. On maintenance, the repository is not archived, and the README shows an active development branch: 3.16.0 alpha 0, with a build status badge for GitHub Actions and one for Azure DevOps, a Discourse link and a developer guide. No last push date was available for this repository, so the development activity visible in the README is the evidence, not a timestamp. The upgrade cost of running from source is the build cycle itself. PGO rebuilds are slow because they compile the interpreter more than once, and the README's subdirectory example exists because mixing debug and top-level builds fails. The README also covers installing multiple versions side by side, which is the intended way to keep a system Python and a built one from colliding. Changes land on main continuously, so a source install tracks an alpha, not a released version. ## Conclusion Compile CPython from source if you need a debug build, a PGO or LTO optimized interpreter, or you are changing the interpreter itself; the README's build path is ./configure, make, make test, sudo make install. Do not build it if you just want to run Python scripts, because python.org distributes installable kits for that. Before adopting a source build, run make test and confirm that no test fails; the README states that a failed test, traceback or core dump means something is wrong, and that is the signal to check your toolchain and dependencies before trusting the binary. ## FAQ ### Why is Python called CPython? The C in the name identifies this as the implementation of Python written in C, which distinguishes it from other implementations of the same language. It is the implementation the Python Software Foundation develops, and the README presents the repository as the Python programming language itself, at version 3.16.0 alpha 0. ### What are the key differences between Python and CPython? Python is the language; CPython is the C implementation of it that this repository contains. In everyday usage the two names point at the same runtime, because CPython is the implementation most people install and run. ### Do I need to install CPython? Not as a separate step. The README says installable Python kits and information about using Python are available at python.org, so you install Python from there. Building this repository from source is for cases that need a debug build, an optimized build, or changes to the interpreter. ### What is CPython used for? It is the interpreter that runs Python programs and the reference for the language's behaviour. This repository is also the working tree for developing the language, which is why the README documents configure options, PGO, LTO and the test suite rather than application usage. ### What is CPython and PyPy? They are two implementations of Python. CPython is the C implementation in this repository; PyPy is a separate implementation built around a just-in-time compiler. This repository's README does not document PyPy, so comparisons on a given workload have to be measured rather than read off this tree. ### What is CPython and Cython? Cython is not an alternative interpreter. It compiles Python-like code, usually with type annotations, into C extension modules that run alongside an interpreter. CPython is the interpreter; Cython is a tool used with one. ## Sources - [Official documentation](https://www.python.org) - [Official README](https://github.com/python/cpython#readme) - [Project repository](https://github.com/python/cpython) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/python-cpython