Quick answer: Python 3.15.0 came out on October 9, 2026, and the current release is 3.15.1 (October 21, 2026). The experimental JIT compiler is still opt-in and still labeled experimental. The Python docs report a 7–8% geometric-mean speedup on x86-64 Linux, but individual programs range from roughly 15% slower to more than 100% faster. Upgrade for the language features (lazy imports, frozendict, UTF-8 by default). Treat the JIT as something to benchmark on your own code, not something to switch on in production.
Python 3.15 is a big release, and the JIT is only one headline. This guide covers what’s new, what the JIT numbers really mean, how to check whether your Python has a JIT at all, how to turn it on, and what to watch for before you upgrade. Every version, date and figure below was checked against python.org and docs.python.org on October 26, 2026.
Python 3.15 at a glance
| Item | Detail |
|---|---|
| First release (3.15.0) | October 9, 2026 |
| Latest release (checked Oct 26, 2026) | 3.15.1, October 21, 2026 |
| Bug-fix support | Roughly every second month for two years |
| Security fixes until | About October 2031 |
| JIT status | Experimental, off unless enabled |
| JIT build dependency | LLVM 21 (build time only) |
Support dates come from PEP 790, the official 3.15 release schedule. Python.org describes 3.15.1 as an expedited security release and the first maintenance release, with around 330 bug fixes from 117 contributors since 3.15.0.
What’s new in Python 3.15
The official “What’s new” page lists the biggest changes as lazy imports, the frozendict and sentinel built-ins, UTF-8 as the default encoding, unpacking in comprehensions, and a stable ABI for free-threaded builds. Here’s what each one means in practice.
- Explicit lazy imports (PEP 810). A new
lazysoft keyword defers loading a module until you first use it.lazy import jsoncreates a lightweight proxy, and the real import happens on first access. It’s aimed at slow startup in large apps and command-line tools. frozendict(PEP 814). A new immutable built-in mapping. It’s hashable when its keys and values are hashable, keeps insertion order, and is not a subclass ofdict.sentinel(PEP 661). A built-in for creating unique sentinel values with a clean representation. They keep identity when copied and work in type expressions with the|operator.- UTF-8 by default (PEP 686).
open("file.txt")without anencodingargument now uses UTF-8 regardless of the system locale. To get the old behavior back, setPYTHONUTF8=0or use-X utf8=0. The docs still recommend passingencodingexplicitly. - Unpacking in comprehensions (PEP 798). You can write
[*L for L in lists]to flatten, and{**d for d in dicts}to merge, instead of nested comprehensions oritertools.chain. - Tachyon, a new sampling profiler. It lives in a new
profilingpackage asprofiling.sampling. It attaches to a running process by PID, needs no code changes, and the docs say it can sample at up to 1,000,000 Hz. - Frame pointers on by default (PEP 831). This helps system-level profilers and debuggers see Python frames.
- Typing additions.
TypedDictwith typed extra items (PEP 728),TypeForm(PEP 747), and disjoint bases (PEP 800). - More color. The interpreter help, unraisable exceptions and many standard-library command-line tools now show color by default.
- Release packaging. The official Windows 64-bit binaries now use the tail-calling interpreter, and the official macOS installer now installs free-threading support by default.
The JIT: what the numbers actually say
Python’s JIT first shipped as an experiment in 3.13. In 3.15 the core team calls it “significantly upgraded.” The official What’s new page gives these figures:
| Comparison | Reported result |
|---|---|
| JIT vs standard interpreter, x86-64 Linux | 7–8% faster (geometric mean) |
| JIT vs tail-calling interpreter, AArch64 macOS | 11–12% faster |
| JIT build vs no-JIT build, range | About 15% slower to over 100% faster |
These come from the pyperformance benchmark suite, and the speedup range excludes one microbenchmark (unpack_sequence). The geometric mean is an average across many benchmarks, so your app can land anywhere in that range. A program that spends its time in C extensions, I/O or the database will see little. Tight pure-Python loops are where the JIT has the most room.
What changed under the hood, per the docs:
- A new tracing frontend that records real execution paths. It understands more bytecode and control flow, including simple object creation, and partly supports generators and overloaded operations. Windows support was added.
- Basic register allocation, so the JIT can skip some stack reads and writes.
- More optimizations, including more constant propagation, avoiding reference counts when it’s safe, and in-place operations on ints and floats.
- Better machine code for x86-64 and AArch64 on macOS and Linux, with lower memory use for generated code.
- GDB and
backtrace()unwinding through JIT frames on supported Linux platforms. That was a major gap in 3.14.
For context, the 3.14 notes described the JIT’s typical effect as “10% slower to 20% faster” and said it was not recommended for production. The 3.15 notes show a wider upside, but they don’t remove the “experimental” label.
Does your Python have a JIT? Check first
You may not need to build anything. The 3.14 release notes said the official macOS and Windows binaries include the experimental JIT, off by default. We could not find a matching explicit statement in the 3.15 notes, so don’t assume. Check your own interpreter:
python3.15 -c "import sys; print(sys._jit.is_available(), sys._jit.is_enabled())"is_available()tells you whether this executable was built with the JIT.is_enabled()tells you whether the JIT is on for this process.
The sys._jit module is an implementation detail of CPython. It isn’t guaranteed to exist in other implementations or future versions. A third function, is_active(), exists only for testing the JIT itself, and the docs say to avoid it for anything else.
How to turn the JIT on
If is_available() returns True, set an environment variable before starting Python:
PYTHON_JIT=1 python3.15 your_script.pyOn Windows PowerShell:
$env:PYTHON_JIT = "1"; py -3.15 your_script.pySetting PYTHON_JIT=0 turns it off. The variable is read at interpreter startup.
Building Python with the JIT
If your build doesn’t include it, you can compile CPython yourself. This is for experimenting, not for servers you care about. The configure option has four modes:
--enable-experimental-jit= |
What it does |
|---|---|
no (default) |
No JIT |
yes |
JIT on; disable with PYTHON_JIT=0 |
yes-off |
JIT built but off; enable with PYTHON_JIT=1 |
interpreter |
For debugging the JIT itself |
Requirements, from the CPython JIT README:
- LLVM 21. You need
clang,llvm-readobj,llvm-objdumpandllvm-dwarfdumpavailable. Users running the finished Python do not need LLVM, only the person building it. - Python 3.11 or newer installed on the build machine.
On Ubuntu or Debian the README suggests LLVM’s llvm.sh script (sudo ./llvm.sh 21). On Fedora 40 or newer it’s sudo dnf install 'clang(major) = 21' 'llvm(major) = 21'. On macOS it’s brew install llvm@21. On Windows, PCbuild\build.bat --experimental-jit downloads LLVM for you. Then:
./configure --enable-experimental-jit=yes-off
make -j
./python -c "import sys; print(sys._jit.is_available())"Using yes-off is the safest choice because you can compare the same binary with and without the JIT by flipping one environment variable.
How to test it fairly on your own code
Don’t trust a single run. A simple approach:
- Pick a real workload. A script, test suite or service endpoint you actually care about.
- Run it both ways with the same binary:
PYTHON_JIT=0andPYTHON_JIT=1. - Warm up, then repeat. A tracing JIT needs hot code before it helps. Short scripts may only pay the cost.
- Compare memory too. Generated machine code uses memory.
- Check correctness. Run your test suite with the JIT on. Report real bugs to the CPython issue tracker, which the docs explicitly ask for.
A tool such as hyperfine works well for the timing runs. We have not benchmarked the JIT ourselves for this article, so we’re not publishing our own speedup number.
Who should upgrade to Python 3.15
Upgrade now if:
- You want the new language features and your dependencies already publish 3.15 wheels.
- You run command-line tools with slow startup. Lazy imports are the practical win there.
- You profile production Python. Tachyon and default frame pointers are real quality-of-life upgrades.
- You’re on macOS and want to try free-threaded Python. The installer now includes it by default.
Wait or test first if:
- You depend on packages with C extensions. Check each one for 3.15 support before moving.
- You read or write text files without an
encodingargument on Windows or non-UTF-8 systems. The UTF-8 default can change behavior. Run with the opt-in encoding warning first. - You need maximum stability. Python 3.14 is still receiving regular fixes; 3.14.9 was released on October 21, 2026, the same day as 3.15.1.
Caveats that matter
- The JIT is experimental. The docs ask for bug reports and don’t recommend production use. The 3.15 notes don’t change that.
- Benchmarks are averages. A 7–8% geometric mean says nothing certain about your app.
- Free-threaded builds and the JIT. The 3.14 notes said free-threaded builds don’t support JIT compilation. We didn’t find an updated statement in the 3.15 notes, so check
sys._jit.is_available()on the build you plan to use. - Linux distros lag. Your distro may not package 3.15 yet. Use
uv,pyenvor the python.org installers rather than replacing the system Python.
FAQ
When was Python 3.15 released?
Python 3.15.0 was released on October 9, 2026. The first maintenance release, 3.15.1, followed on October 21, 2026.
Is the Python 3.15 JIT turned on by default?
No. It’s opt-in. Set PYTHON_JIT=1 if your interpreter was built with the JIT, or build CPython with --enable-experimental-jit.
How much faster is the Python 3.15 JIT?
The official What’s new page reports a 7–8% geometric-mean improvement over the standard interpreter on x86-64 Linux, and 11–12% over the tail-calling interpreter on AArch64 macOS. Results for individual programs range from about 15% slower to over 100% faster.
Do I need LLVM to use the JIT?
Only if you build CPython yourself. Python 3.15’s JIT uses LLVM 21 at build time to generate code templates. People running a finished Python don’t need it.
Is Python 3.15 safe for production?
The language and standard library are a stable release. The JIT is the experimental part. Most teams should wait for their dependencies to support 3.15, test on a staging system, and leave the JIT off in production.
Will my old code break with UTF-8 as the default encoding?
Possibly, if it opens text files without an encoding argument on a system that wasn’t using UTF-8. Add explicit encodings or set PYTHONUTF8=0 to keep the old behavior while you fix things.
Sources
All checked October 26, 2026.
- What’s new in Python 3.15 (docs.python.org)
- Python 3.15.1 release page (python.org)
- Python downloads and release dates (python.org)
- PEP 790 – Python 3.15 release schedule
- Configure options: –enable-experimental-jit (docs.python.org)
- CPython JIT README (Tools/jit)
- sys._jit reference (docs.python.org)
- What’s new in Python 3.14, JIT binary notes (docs.python.org)
- Using Python on macOS: free-threaded installs (docs.python.org)
By Early Adopted Editorial Team. Last updated: October 26, 2026