What's Actually New in Python 3.13 and 3.14

Python 3.13 (October 2024) and 3.14 (October 2025) are the two most consequential releases the language has had in years. Between them, they touch the thing people have complained about for two decades — the Global Interpreter Lock — and quietly modernize half of the daily developer experience: the REPL, error messages, type annotations, string templating, debugging, and compression.

This post is a plain-language tour of what changed and what it means in practice. If you also want to modernize your tooling, read the companion post on uv, the tool that replaces pyenv, pip, venv, and pipx.

The ten things worth knowing

1. Python 3.13 shipped a redesigned interactive shell — colors, multi-line editing, sane shortcuts — and even friendlier error messages with “did you mean…?” suggestions.
2. An experimental 3.13 build removes the GIL (free-threading), enabling real parallelism across CPU cores; in 3.14 free-threading became officially supported.
3. JIT compilation landed in 3.13 as an experimental, off-by-default foundation for future speedups.
4. 3.14 makes type annotations lazy (deferred evaluation), improving startup time and killing a whole class of annotation workarounds.
5. Subinterpreters — multiple isolated Python interpreters in one process — are now usable from Python code, giving you another concurrency option.
6. Template strings (t-strings) in 3.14 make dynamic content — HTML, SQL — safer to build than f-strings.
7. The incremental garbage collector shipped in 3.14.0 to reduce pause times in large, long-running applications — but it was reverted in 3.14.5 (June 2026) back to the 3.13-style generational GC after memory-pressure regressions, with possible reintroduction in a later release. (Accurate at publication; corrected since.)
8. Zstandard (zstd) compression is now in the standard library — faster and tighter than gzip for most workloads.
9. Live-process debugging: 3.14 lets you attach a debugger to a running Python process — including, carefully, in production.
10. Both releases removed long-deprecated modules — the “dead batteries” cleanup — so legacy code needs a checkup before upgrading.

Python 3.13: quality of life, plus two experiments

The new REPL and better errors

The interactive shell finally caught up with the decade: multi-line editing that works, color-coded output and tracebacks, exit that just exits. Error messages continued their glow-up — misspell a keyword argument or a module attribute and Python now suggests what you probably meant. Small thing, huge cumulative time savings, especially for people learning the language.

Free-threading: the GIL becomes optional

The Global Interpreter Lock has always meant one thread executes Python bytecode at a time — multithreaded Python could wait in parallel but not compute in parallel. Python 3.13 shipped a separate experimental build (python3.13t) with the GIL removed.

The bridge analogy. Picture a bridge that only ever allowed one vehicle to cross at a time, no matter how many lanes it had. Free-threading opens all the lanes. But some older vehicles — C extensions written assuming the GIL — aren’t certified for the new bridge yet, so adoption needs care.

In 3.13 this was strictly experimental: single-threaded code ran noticeably slower on the free-threaded build, and many C extensions weren’t compatible. In 3.14, free-threading was promoted to officially supported (PEP 779) — still a separate build, but no longer a science project: the single-threaded penalty shrank substantially and the major scientific and web libraries have been landing support. If you have genuinely CPU-bound multithreaded workloads, 3.14’s free-threaded build is now worth a real evaluation.

JIT compilation: the foundation is laid

3.13 added an experimental just-in-time compiler (off by default, enabled at build time). Gains are modest so far — this release was about landing the architecture, not the speed.

The barista analogy. A new barista makes your regular order by reading the recipe every time. After a hundred repetitions, they’ve internalized it and it’s faster. That’s the JIT: it watches which code paths run hot and compiles them to faster machine code as the program runs.

Expect this to compound over the next several releases rather than deliver a big bang.

Housekeeping

3.13 completed the “dead batteries” removal (PEP 594) — nineteen crusty stdlib modules (cgi, telnetlib, pipes, …) are gone. It also made frame locals behave predictably (PEP 667), which matters if you use debuggers or clever locals() tricks.

Python 3.14: the features release

Deferred annotations: type hints stop costing you at startup

Until now, Python evaluated every type annotation eagerly at import time — whether or not anything ever looked at them.

The buffet analogy. Imagine preparing a full buffet every morning regardless of whether anyone eats. Deferred annotations (PEP 649/749) cook the dish only when someone orders it: annotations are stored lazily and evaluated on access.

Practical wins: faster imports, no more from __future__ import annotations dance, forward references that just work, and the end of quoting-your-own-class-name in method signatures.

Subinterpreters: concurrency without shared chaos

PEP 734 exposes multiple isolated interpreters inside a single process to pure Python code (concurrent.interpreters), each with its own GIL.

The office analogy. A large building where each team works in its own soundproof room — no interference, shared infrastructure. That’s subinterpreters: isolation like multiprocessing, but cheaper, in one process.

Together with free-threading, Python now has a genuine menu of concurrency options: asyncio for I/O-bound, free-threading for shared-memory parallelism, subinterpreters for isolated parallelism, multiprocessing when you want OS-level separation.

Template strings: f-strings that don’t blend everything together

PEP 750 adds t-strings: t"Hello {name}" produces a template object instead of a final string, so the consuming code can see — and safely escape — each interpolated value before assembly.

The smoothie vs. LEGO analogy. An f-string is a smoothie: once blended, you can’t separate the ingredients, so if one of them was user input headed for SQL or HTML, it’s already too late. A t-string is LEGO: every block stays visible and inspectable until you decide how to snap them together.

This is the foundation for injection-safe HTML templating and SQL building in libraries — expect frameworks to adopt it broadly.

Debugging, memory, and compression

• Attach to a live process (PEP 768): a zero-overhead-when-idle interface lets debuggers safely attach to a running Python program — pdb can now connect to a live PID. For diagnosing a wedged production process, this is gold.
• Incremental garbage collection: 3.14.0 introduced an incremental collector for shorter GC pauses and smoother latency on large heaps. Update: this was reverted in 3.14.5 (June 2026) — memory-pressure regressions led the core team to restore the 3.13-style generational collector, with the incremental approach possibly returning in a future release. This post was accurate when published in January 2026; on current 3.14 (3.14.5+) you’re back on the generational GC. See the discussion on reverting the incremental GC.
• compression.zstd (PEP 784): Zstandard in the stdlib — dramatically faster than gzip at comparable or better ratios, with tarfile/zipfile/shutil integration.
• The REPL got syntax highlighting, and error messages got another round of polish.

How I’d adopt this

1. Upgrade path: if you’re on 3.11/3.12, target 3.13 or 3.14 directly — the upgrade friction is mostly deprecated-module removals. Run your test suite with -W error::DeprecationWarning first.
2. Try the new REPL and error messages — no action needed, they’re the default.
3. Deferred annotations: on 3.14, delete from __future__ import annotations and un-quote forward references as you touch files.
4. Free-threading: evaluate the 3.14 free-threaded build on a CPU-bound workload in a branch. Check your C-extension dependencies for compatibility first.
5. t-strings: adopt where you build HTML or SQL by hand; watch your web framework’s release notes for native support.
6. zstd: swap in for gzip anywhere you compress logs, artifacts, or datasets.

Gotchas to check before upgrading

• Code importing removed “dead battery” modules (cgi, telnetlib, imghdr, …) breaks on 3.13 — most have drop-in PyPI replacements.
• Tools that poke at frame locals (custom debuggers, profilers) may need updates for the PEP 667 semantics.
• Custom GC tuning (gc.set_threshold calls) deserves a re-benchmark after any upgrade. Note that the incremental collector added in 3.14.0 was reverted in 3.14.5, so current 3.14 is back on the generational collector — if you tuned for the brief incremental window, re-check against generational behavior.
• The free-threaded build requires compatible wheels — a dependency without a cp314t wheel means compiling from source or waiting.

Both releases reward the same habit: upgrade early in a branch, run the tests loudly, and read the “What’s New” documents — they’re genuinely well-written.