Python 3.16 Alpha 1 Released, and Its JIT May Not Survive the Cycle
The first preview of Python 3.16 shipped October 13. But the year's biggest fight, over the experimental JIT, is far from settled.
Python 3.16.0a1 has been released as the first of seven planned previews before a stable release, and the announcement landed on the Python Insider blog. Savannah Ostrowski runs this cycle, which means she's the one fielding the bug reports.
At a glance, there's nothing here worth a blog post. No new syntax. No flashy features. That's fine, because that's exactly what an alpha is for.
The interesting part is what 3.16 is meant to settle: whether CPython keeps its experimental JIT compiler. That fight isn't over. It's the main event of the whole cycle.
The JIT question (and the bet underneath it)
CPython has dragged an experimental Just-in-Time compiler around in its main branch since 3.13. In 3.15 it reportedly delivers roughly a 4 to 12 percent speedup on pyperformance, but only if you flip PYTHON_JIT=1 and build it yourself.
The Steering Council grew impatient. On June 5, 2026 it issued something close to an ultimatum. The JIT had been built without a proper Standards Track PEP, and the SC honestly admitted it hadn't been strict about the process itself. The demand was simple: submit a real PEP arguing for the JIT as supported, non-experimental code, and do it within six months.
No PEP in time, and the JIT gets pulled from main and shunted into a fork.
The deadline was roughly a half year out. The community met it. PEP 836, "JIT Go Brrr," landed July 2, about a month after the demand, authored by Ostrowski, Ken Jin, and Brandt Bucher.
It's a time-bounded path rather than a declaration of victory. Year one is developer experience. The big move is ditching trace recording for a method-based design that compiles whole functions. Easier to maintain. Far simpler to debug. And it can roll back to tracing if the method-based approach fails.
Year two is numbers. The target is at least a 20 percent geometric-mean improvement on pyperformance, measured as JIT plus free-threading versus the free-threaded interpreter alone. If an optimization breaks the free-threaded build, it gets rejected outright.
Here's the thing nobody's talking about much. Even PEP 841, which has nothing to do with the JIT, still has to note that the compiler project is on hold. Development was paused pending SC acceptance. So the roadmap exists, but no new JIT work shipped in 3.16.0a1. The code you're downloading today is not the future of the JIT.
And that future rides hard on free-threading. Python keeps betting on making the GIL optional under PEP 703, and the two are moving together rather than one or the other. That's also why 3.16 lists more supported platforms for these advanced builds, including iOS and Android. The parallelism wager is real, and it's where the performance money is going.
Language changes still being fought over
Because 3.16 still takes new features, a stack of Standards Track PEPs is being worked right now. These are the ones to watch.
PEP 840 wants to fix a class-name resolution wart as old as Python itself. Jeremy Hylton and Guido van Rossum wrote it. A name used before its assignment resolves differently depending on whether a class sits at module level or nested in a function. It's subtle. Guido once suggested you just don't write code that abuses it.
PEP 841 proposes frozen-set syntax. f{1, 2, 3} becomes a frozenset. f{'a': 1} a frozendict. Since immutability comes from the syntax itself, the compiler can fold those constants and cache them in .pyc files, even share them across free-threading. It's backward compatible, because f{ is a syntax error today, and it borrows the f-string prefix you already know.
PEP 843 adds an export statement to kill the "name twice" problem. You import a value and it lands in __all__ in a single line. Hub modules like a library's __init__.py no longer repeat everything. It's a soft keyword, so existing code stays intact.
PEP 844 gives you public() and private() builtins as decorators, keeping __all__ in sync at the point of definition. Barry Warsaw pushed it. Its sibling PEP 842 was withdrawn, so Warsaw's version only handles the bookkeeping, leaving runtime enforcement for later.
There are more if you want the full index: JSON serialization gets extensible (PEP 837), pyvenv.cfg gains a python-version field (PEP 838), and the C API picks up frozen-set helpers (PEP 839).
What's actually inside the alpha
The draft "What's New in Python 3.16" is still a draft, but it already lists real changes that made it in. The re module gets set operations in character classes, so [a-z--[aeiou]] matches consonants. Unicode property escapes like \p{Lu} show up. Half-turn trig functions arrive: math.acospi(), math.sinpi(), and friends, standardized in C23.
curses got a major overhaul, with multi-terminal support and full mouse handling. zipfile can now remove and repack archives to shrink them. unicodedata jumped to Unicode 18.0.0. New build flags added options for curses, zlib, and bzip2, and the bundled libmpdec is gone for good.
Meanwhile the trimmings are being cleared out. The asyncio event-loop policy system, long deprecated, is finally dead. Several stale symbols across shutil, mimetypes, and logging get swept up too.
None of it is headline news. It's standard-library polish and cleanup, which is what an alpha should be. Set expectations here carefully: don't expect a feature dump. The big language changes are still potentially coming, by the May 2027 beta freeze.
Try it (but keep it out of production)
Head here to grab 3.16.0a1 from python.org's downloads page. The draft docs are available here. Alpha 2 is scheduled for November 10, 2026.
The team specifically wants library and application maintainers to test against this. That's not a deploy order. It's a "break it, then report what you broke" request, and it's a decent reminder that Python is still a language a huge crowd builds together.
