Skip to content

What is PEP 779?

by Tim Hopper

PEP 779: Criteria for supported status for free-threaded Python is the checklist that moved free-threaded Python from experiment to supported build in Python 3.14. Authored by Thomas Wouters, Matt Page, and Sam Gross, it sets the criteria the Steering Council used to promote the free-threaded build from “experimental” to “officially supported”, and was accepted on 16 June 2025.

Trace the three-phase rollout

When the Steering Council accepted PEP 703: Making the Global Interpreter Lock Optional in CPython in 2023, it did not commit to ever shipping a GIL-less Python as the default. Instead it sketched a three-phase rollout:

  • Phase I: ship the free-threaded build as an opt-in, explicitly experimental variant. This started in Python 3.13.
  • Phase II: promote the free-threaded build to officially supported, but still optional and separate from the default build.
  • Phase III: make the free-threaded build the default, retiring the GIL-enabled build.

The acceptance left the criteria for moving between phases vague because, in 2023, nobody knew whether the implementation would hold up or whether the single-threaded performance cost would stay manageable. PEP 779 exists to write those criteria down for the move to Phase II.

Measure Phase II readiness

PEP 779 defines the bar the Steering Council used to decide whether the free-threaded build was ready for official support. It requires:

  1. Single-threaded performance stays close to the GIL build. The PEP sets a 15% regression as the hard ceiling on pyperformance (CPython’s standard benchmark suite). By Python 3.14 the gap had closed to 5-10%.
  2. Memory overhead stays bounded. Free-threaded runs can use at most 20% more memory than GIL runs on the pyperformance geometric mean.
  3. The C API is stable enough to port against. No breaking changes to the C API the free-threaded build exposes, and enough third-party extensions have adopted it to prove the porting path works.
  4. Community and maintainer commitment exists. Core developers have to be willing to keep maintaining the free-threaded build through the 3.14 cycle, and the ecosystem has to show uptake (wheel coverage on PyPI plus working debuggers and profilers).

The PEP does not set criteria for Phase III. That decision is left to a future PEP once Phase II has run long enough to judge the cost of supporting two builds against the benefit of removing the GIL by default.

Ship free-threaded Python in 3.14

With PEP 779 accepted, Python 3.14 ships the free-threaded build as officially supported. The Python 3.14 What’s New page describes the status this way: the specializing adaptive interpreter runs in free-threaded mode, the single-threaded performance gap has narrowed to 5-10%, and the C API changes from PEP 703 are finished.

Phase II does not promise four things, though:

  • The default CPython build still has the GIL. A standard python3.14 from python.org behaves the same as 3.13 with respect to threads. Only the t-suffixed build (for example python3.14t) runs without the GIL.
  • Every PyPI wheel works. C extensions need free-threaded wheels, and coverage is uneven outside the scientific-Python core. Pip-installing a package without a free-threaded wheel falls back to a source build, which needs a compiler.
  • Threaded Python code is automatically faster. Lifting the GIL only helps CPU-bound pure-Python code that actually uses threads. I/O-bound code and code that already releases the GIL in C extensions see little or no change.
  • Phase III is scheduled. PEP 779 leaves the Phase III decision open. Whether and when the free-threaded build becomes the default is a separate, future conversation.

See what the ruling unlocked

Before PEP 779, “free-threaded Python” was a future promise with no written test for whether it was delivered. The PEP turned that promise into a checklist the Steering Council could rule on, and the ruling unlocked a shift: library authors can now commit to supporting the free-threaded build without betting on experimental status, and CI and packaging tools can treat it as a first-class target instead of a research project.

In practice, that means a project can add python3.14t to CI, publish cp314t wheels, and document free-threaded support without calling it experimental.

If you want to try the free-threaded build yourself, Try free-threaded Python with uv walks through installing both builds side by side and measuring the speedup on a CPU-bound workload. To adopt it in an existing project, see How to use free-threaded Python in a uv project.

Learn More

Last updated on
What is PEP 773?What is PEP 8?

Please submit corrections and feedback...