The best new features and fixes in Python 3.13

The first beta of Python 3.13 has just been released. This article presents a rundown of the most significant new features in Python 3.13 and what they mean for Python developers. Things may change between now and the first production release of 3.13, but the first beta means all the major feature additions and changes are now frozen.

New features in the Python 3.13 first beta

Here’s a first look at these new features in the Python 3.13 beta release:

• The experimental JIT
• The no-GIL build of Python
• A new REPL
• Improved error messages
• Enhancements to Python types
• No more “dead batteries”

The experimental JIT

Python 3.11 introduced the Specializing Adaptive Interpreter. When the interpreter detects that some operations predictably involve the same types, those operations are “specialized.” The generic bytecode used for that code is swapped with bytecode specific to working with those types, which delivers speed boosts of anywhere from 10% to 25% for those regions of the code.

Python 3.12 brought more specializations and other refinements to the interpreter. Now, Python 3.13 adds new elements to the JIT that generate actual machine code at runtime, instead of just specialized bytecode. The resulting speedup isn’t much just yet—maybe 5%—but it paves the way for future optimizations that weren’t previously possible.

Right now, the JIT is considered experimental—it’s not enabled by default, and can only be enabled by compiling CPython from source with certain flags. If in time it yields a significant performance boost (5% or more), and doesn’t impose a large management burden on the CPython team or Python’s users as a whole, it’ll become a fully supported build option. Whether or not it will be enabled for official releases will still be up to the managers for a given platform’s CPython builds.

The no-GIL ‘free-threaded’ build of Python

The official term for possible future versions of CPython with no Global Interpreter Lock (or GIL) is “free-threaded CPython.” This CPython build allows threads to run fully in parallel, without mediation from the GIL. To that end, CPU-bound work that once only benefited from being run in multiple processes can run in multiple threads.

Free-threaded CPython is also experimental. It’s not enabled by default in the shipped builds, so it needs to be enabled at compile time. If future work with the free-threaded builds shows it can improve multithreaded performance without impacting single-threaded performance, it’ll be promoted to a fully supported option. In time, the free-threaded build of CPython may become the default.

A new REPL

The REPL, or interactive interpreter, launches when you run Python from the command line without executing a program. Python 3.13’s REPL has enhancements to make it less stodgy and more like an actual editor:

• Output to the console now has color enabled by default. This enhancement provides richer error messages, for instance.
• You can open the interactive pydoc help browser by pressing F1.
• You can browse the command-line history with F2.
• You can paste large blocks of code more easily by pressing F3 to enable a special block-paste mode.
• You can just type exit or quit, instead of exit() or quit(), to leave the REPL.

Note that these improvements currently are only available on Linux and macOS. They are not available on Microsoft Windows, not even when using the new Windows Terminal console host.

Improved error messages

Error traces in Python have become more precise and detailed over the last two releases. Python 3.13 continues on that trajectory.

• If you attempt to import something that has the same name as the module currently in context, Python will provide a detailed error to that effect, and encourage you to rename the current module. This is a very frequent source of bugs—and not only for beginners. It’s a common mistake to name a module after something in the standard library.
• If you pass a function an incorrect keyword argument, the error will suggest some possible correct arguments, based on what’s available in the function being called.

Enhancements to Python types

Python’s type hinting system has expanded in functionality and utility with each new version. Version 3.13 adds three big new changes.

Type parameters support defaults

typing.TypeVar, typing.ParamSpec, and typing.TypeVarTuple all let you define defaults to be used if no type is explicitly specified. For instance:

T = TypeVar("T", default=str)

In cases where T is not explicitly defined when used, str is assumed to be the default.

typing.TypeIs for type narrowing

In Python generally, we can use isinstance() to make decisions based on whether or not something is a given type. typing.TypeIs lets us do the same thing in Python’s type hinting mechanisms. This way, functions used to validate whether or not something is a given type can be annotated to show they perform that narrowing behavior, rather than just a return type. This is useful as a way to add precise type checker coverage to those functions.

typing.ReadOnly for read-only annotation

The typing.TypedDict type was created to annotate dictionaries with fixed types for the values associated with certain keys. typing.Readonly lets you annotate specific values in a TypedDict as read-only. An example is a list that you can only append to or pop from, not replace with a string or other type.

No more ‘dead batteries’

Python 3.11 identified a slew of Python standard library modules that were obsolete and no longer being maintained. The plan was to mark them as deprecated for 3.11 and 3.12, and then remove them entirely in Python 3.13. As of now, those “dead batteries” (as they’ve been called) are now permanently removed. Many of the removed modules can be replaced with third-party modules, or their functionality can be emulated using other standard library components.

Users can expect more deprecations to come over the next three versions of Python, as well. Most are methods for various standard library components that are rarely used or undocumented.