What’s New In Python 3.13 (original) (raw)

Editors:

Adam Turner and Thomas Wouters

This article explains the new features in Python 3.13, compared to 3.12. Python 3.13 was released on October 7, 2024. For full details, see the changelog.

See also

PEP 719 – Python 3.13 Release Schedule

Summary – Release Highlights

Python 3.13 is the latest stable release of the Python programming language, with a mix of changes to the language, the implementation and the standard library. The biggest changes include a new interactive interpreter, experimental support for running in a free-threaded mode (PEP 703), and a Just-In-Time compiler (PEP 744).

Error messages continue to improve, with tracebacks now highlighted in color by default. The locals() builtin now has defined semantics for changing the returned mapping, and type parameters now support default values.

The library changes contain removal of deprecated APIs and modules, as well as the usual improvements in user-friendliness and correctness. Several legacy standard library modules have now been removed following their deprecation in Python 3.11 (PEP 594).

This article doesn’t attempt to provide a complete specification of all new features, but instead gives a convenient overview. For full details refer to the documentation, such as the Library Referenceand Language Reference. To understand the complete implementation and design rationale for a change, refer to the PEP for a particular new feature; but note that PEPs usually are not kept up-to-date once a feature has been fully implemented. See Porting to Python 3.13 for guidance on upgrading from earlier versions of Python.


Interpreter improvements:

Python data model improvements:

Significant improvements in the standard library:

Security improvements:

C API improvements:

New typing features:

Platform support:

Important removals:

Release schedule changes:

PEP 602 (“Annual Release Cycle for Python”) has been updated to extend the full support (‘bugfix’) period for new releases to two years. This updated policy means that:

New Features

A better interactive interpreter

Python now uses a new interactive shell by default, based on code from the PyPy project. When the user starts the REPL from an interactive terminal, the following new features are now supported:

To disable the new interactive shell, set the PYTHON_BASIC_REPL environment variable. For more on interactive mode, see Interactive Mode.

(Contributed by Pablo Galindo Salgado, Łukasz Langa, and Lysandros Nikolaou in gh-111201 based on code from the PyPy project. Windows support contributed by Dino Viehland and Anthony Shaw.)

Improved error messages

AttributeError: module 'random' has no attribute 'randint' (consider renaming '/home/me/random.py' since it has the same name as the standard library module named 'random' and prevents importing that standard library module)
Similarly, if a script has the same name as a third-party module that it attempts to import and this results in errors, we also display a more helpful error message:
$ python numpy.py
Traceback (most recent call last):
File "/home/me/numpy.py", line 1, in
import numpy as np
File "/home/me/numpy.py", line 3, in
np.array([1, 2, 3])
^^^^^^^^
AttributeError: module 'numpy' has no attribute 'array' (consider renaming '/home/me/numpy.py' if it has the same name as a library you intended to import)
(Contributed by Shantanu Jain in gh-95754.)

Free-threaded CPython

CPython now has experimental support for running in a free-threaded mode, with the global interpreter lock (GIL) disabled. This is an experimental feature and therefore is not enabled by default. The free-threaded mode requires a different executable, usually called python3.13t or python3.13t.exe. Pre-built binaries marked as free-threaded can be installed as part of the official Windowsand macOS installers, or CPython can be built from source with the --disable-gil option.

Free-threaded execution allows for full utilization of the available processing power by running threads in parallel on available CPU cores. While not all software will benefit from this automatically, programs designed with threading in mind will run faster on multi-core hardware.The free-threaded mode is experimental and work is ongoing to improve it: expect some bugs and a substantial single-threaded performance hit. Free-threaded builds of CPython support optionally running with the GIL enabled at runtime using the environment variable PYTHON_GIL or the command-line option -X gil=1.

To check if the current interpreter supports free-threading, python -VVand sys.version contain “experimental free-threading build”. The new sys._is_gil_enabled() function can be used to check whether the GIL is actually disabled in the running process.

C-API extension modules need to be built specifically for the free-threaded build. Extensions that support running with the GIL disabled should use the Py_mod_gil slot. Extensions using single-phase init should use PyUnstable_Module_SetGIL() to indicate whether they support running with the GIL disabled. Importing C extensions that don’t use these mechanisms will cause the GIL to be enabled, unless the GIL was explicitly disabled with the PYTHON_GIL environment variable or the-X gil=0 option. pip 24.1 or newer is required to install packages with C extensions in the free-threaded build.

This work was made possible thanks to many individuals and organizations, including the large community of contributors to Python and third-party projects to test and enable free-threading support. Notable contributors include: Sam Gross, Ken Jin, Donghee Na, Itamar Oren, Matt Page, Brett Simmers, Dino Viehland, Carl Meyer, Nathan Goldbaum, Ralf Gommers, Lysandros Nikolaou, and many others. Many of these contributors are employed by Meta, which has provided significant engineering resources to support this project.

An experimental just-in-time (JIT) compiler

When CPython is configured and built using the --enable-experimental-jit option, a just-in-time (JIT) compiler is added which may speed up some Python programs. On Windows, use PCbuild/build.bat --experimental-jit to enable the JIT or --experimental-jit-interpreter to enable the Tier 2 interpreter. Build requirements and further supporting information are contained at Tools/jit/README.md.

The --enable-experimental-jit option takes these (optional) values, defaulting to yes if --enable-experimental-jit is present without the optional value.

The internal architecture is roughly as follows:

(JIT by Brandt Bucher, inspired by a paper by Haoran Xu and Fredrik Kjolstad. Tier 2 IR by Mark Shannon and Guido van Rossum. Tier 2 optimizer by Ken Jin.)

Defined mutation semantics for locals()

Historically, the expected result of mutating the return value oflocals() has been left to individual Python implementations to define. Starting from Python 3.13, PEP 667 standardises the historical behavior of CPython for most code execution scopes, but changes optimized scopes(functions, generators, coroutines, comprehensions, and generator expressions) to explicitly return independent snapshots of the currently assigned local variables, including locally referenced nonlocal variables captured in closures.

This change to the semantics of locals() in optimized scopes also affects the default behavior of code execution functions that implicitly target locals() if no explicit namespace is provided (such as exec() and eval()). In previous versions, whether or not changes could be accessed by callinglocals() after calling the code execution function was implementation-dependent. In CPython specifically, such code would typically appear to work as desired, but could sometimes fail in optimized scopes based on other code (including debuggers and code execution tracing tools) potentially resetting the shared snapshot in that scope. Now, the code will always run against an independent snapshot of the local variables in optimized scopes, and hence the changes will never be visible in subsequent calls to locals(). To access the changes made in these cases, an explicit namespace reference must now be passed to the relevant function. Alternatively, it may make sense to update affected code to use a higher level code execution API that returns the resulting code execution namespace (e.g. runpy.run_path() when executing Python files from disk).

To ensure debuggers and similar tools can reliably update local variables in scopes affected by this change, FrameType.f_locals now returns a write-through proxy to the frame’s local and locally referenced nonlocal variables in these scopes, rather than returning an inconsistently updated shared dict instance with undefined runtime semantics.

See PEP 667 for more details, including related C API changes and deprecations. Porting notes are also provided below for the affectedPython APIs and C APIs.

(PEP and implementation contributed by Mark Shannon and Tian Gao ingh-74929. Documentation updates provided by Guido van Rossum and Alyssa Coghlan.)

Support for mobile platforms

PEP 730: iOS is now a PEP 11 supported platform, with thearm64-apple-ios and arm64-apple-ios-simulator targets at tier 3 (iPhone and iPad devices released after 2013 and the Xcode iOS simulator running on Apple silicon hardware, respectively).x86_64-apple-ios-simulator(the Xcode iOS simulator running on older x86_64 hardware) is not a tier 3 supported platform, but will have best-effort support. (PEP written and implementation contributed by Russell Keith-Magee ingh-114099.)

PEP 738: Android is now a PEP 11 supported platform, with theaarch64-linux-android and x86_64-linux-android targets at tier 3. The 32-bit targets arm-linux-androideabi and i686-linux-androidare not tier 3 supported platforms, but will have best-effort support. (PEP written and implementation contributed by Malcolm Smith ingh-116622.)

Other Language Changes

New Modules

Improved Modules

argparse

array

ast

asyncio

base64

compileall

concurrent.futures

configparser

copy

ctypes

dbm

dis

doctest

email

enum

fractions

glob

importlib

io

ipaddress

itertools

marshal

math

mimetypes

mmap

multiprocessing

os

os.path

pathlib

pdb

queue

random

re

shutil

site

sqlite3

ssl

statistics

subprocess

sys

tempfile

time

tkinter

traceback

types

typing

unicodedata

venv

warnings

xml

zipimport

Optimizations

Removed Modules And APIs

PEP 594: Remove “dead batteries” from the standard library

PEP 594 proposed removing 19 modules from the standard library, colloquially referred to as ‘dead batteries’ due to their historic, obsolete, or insecure status. All of the following modules were deprecated in Python 3.11, and are now removed:

(Contributed by Victor Stinner and Zachary Ware in gh-104773 and gh-104780.)

2to3

builtins

configparser

importlib.metadata

locale

opcode

optparse

pathlib

re

tkinter.tix

turtle

typing

unittest

urllib

webbrowser

New Deprecations

Pending removal in Python 3.14

Pending removal in Python 3.15

Pending removal in Python 3.16

Pending removal in Python 3.17

Pending removal in future versions

The following APIs will be removed in the future, although there is currently no date scheduled for their removal.

CPython Bytecode Changes

C API Changes

New Features

Changed C APIs

Limited C API Changes

Removed C APIs

Deprecated C APIs

Pending removal in Python 3.14

Pending removal in Python 3.15

Pending removal in Python 3.18

Pending removal in future versions

The following APIs are deprecated and will be removed, although there is currently no date scheduled for their removal.

Build Changes

Porting to Python 3.13

This section lists previously described changes and other bugfixes that may require changes to your code.

Changes in the Python API

Changes in the C API

Regression Test Changes