Skip to content

Latest commit

 

History

History
2795 lines (2112 loc) · 107 KB

3.13.rst

File metadata and controls

2795 lines (2112 loc) · 107 KB

What's New In Python 3.13

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 :ref:`changelog <changelog>`.

.. seealso::

   :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 :func:`locals` builtin now has :ref:`defined semantics <whatsnew313-locals-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 :ref:`Library Reference <library-index>` and :ref:`Language Reference <reference-index>`. 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:

  • Python 3.9--3.12 have one and a half years of full support, followed by three and a half years of security fixes.
  • Python 3.13 and later have two years of full support, followed by three years of security fixes.

New Features

A better interactive interpreter

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

  • Multiline editing with history preservation.
  • Direct support for REPL-specific commands like help, exit, and quit, without the need to call them as functions.
  • Prompts and tracebacks with :ref:`color enabled by default <using-on-controlling-color>`.
  • Interactive help browsing using F1 with a separate command history.
  • History browsing using F2 that skips output as well as the :term:`>>>` and :term:`...` prompts.
  • "Paste mode" with F3 that makes pasting larger blocks of code easier (press F3 again to return to the regular prompt).

To disable the new interactive shell, set the :envvar:`PYTHON_BASIC_REPL` environment variable. For more on interactive mode, see :ref:`tut-interac`.

(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

  • The interpreter now uses color by default when displaying tracebacks in the terminal. This feature :ref:`can be controlled <using-on-controlling-color>` via the new :envvar:`PYTHON_COLORS` environment variable as well as the canonical |NO_COLOR|_ and |FORCE_COLOR|_ environment variables. (Contributed by Pablo Galindo Salgado in :gh:`112730`.)

  • A common mistake is to write a script with the same name as a standard library module. When this results in errors, we now display a more helpful error message:

    $ python random.py
Traceback (most recent call last):
  File "/home/me/random.py", line 1, in <module>
    import random
  File "/home/me/random.py", line 3, in <module>
    print(random.randint(5))
          ^^^^^^^^^^^^^^
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 <module>
    import numpy as np
  File "/home/me/numpy.py", line 3, in <module>
    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`.)

  • The error message now tries to suggest the correct keyword argument when an incorrect keyword argument is passed to a function.

    >>> "Better error messages!".split(max_split=1)
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    "Better error messages!".split(max_split=1)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
TypeError: split() got an unexpected keyword argument 'max_split'. Did you mean 'maxsplit'?

    (Contributed by Pablo Galindo Salgado and Shantanu Jain in :gh:`107944`.)

Free-threaded CPython

CPython now has experimental support for running in a free-threaded mode, with the :term:`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 :ref:`Windows <install-freethreaded-windows>` and :ref:`macOS <install-freethreaded-macos>` installers, or CPython can be built from source with the :option:`--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 :envvar:`PYTHON_GIL` or the command-line option :option:`-X gil=1`.

To check if the current interpreter supports free-threading, :option:`python -VV <-V>` and :data:`sys.version` contain "experimental free-threading build". The new :func:`!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 :term:`GIL` disabled should use the :c:data:`Py_mod_gil` slot. Extensions using single-phase init should use :c:func:`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 :envvar:`PYTHON_GIL` environment variable or the :option:`-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.

.. seealso::

   :pep:`703` "Making the Global Interpreter Lock Optional in CPython"
   contains rationale and information surrounding this work.

   `Porting Extension Modules to Support Free-Threading
   <https://py-free-threading.github.io/porting/>`_: A community-maintained
   porting guide for extension authors.

An experimental just-in-time (JIT) compiler

When CPython is configured and built using the :option:`!--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 :file:`Tools/jit/README.md`.

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

  • no: Disable the entire Tier 2 and JIT pipeline.
  • yes: Enable the JIT. To disable the JIT at runtime, pass the environment variable PYTHON_JIT=0.
  • yes-off: Build the JIT but disable it by default. To enable the JIT at runtime, pass the environment variable PYTHON_JIT=1.
  • interpreter: Enable the Tier 2 interpreter but disable the JIT. The interpreter can be disabled by running with PYTHON_JIT=0.

The internal architecture is roughly as follows:

  • We start with specialized Tier 1 bytecode. See :ref:`What's new in 3.11 <whatsnew311-pep659>` for details.
  • When the Tier 1 bytecode gets hot enough, it gets translated to a new purely internal intermediate representation (IR), called the Tier 2 IR, and sometimes referred to as micro-ops ("uops").
  • The Tier 2 IR uses the same stack-based virtual machine as Tier 1, but the instruction format is better suited to translation to machine code.
  • We have several optimization passes for Tier 2 IR, which are applied before it is interpreted or translated to machine code.
  • There is a Tier 2 interpreter, but it is mostly intended for debugging the earlier stages of the optimization pipeline. The Tier 2 interpreter can be enabled by configuring Python with --enable-experimental-jit=interpreter.
  • When the JIT is enabled, the optimized Tier 2 IR is translated to machine code, which is then executed.
  • The machine code translation process uses a technique called copy-and-patch. It has no runtime dependencies, but there is a new build-time dependency on LLVM.
.. seealso:: :pep:`744`

(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 :py:func:`locals`

Historically, the expected result of mutating the return value of :func:`locals` 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 :term:`optimized scopes <optimized scope>` (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 :func:`locals` in optimized scopes also affects the default behavior of code execution functions that implicitly target :func:`!locals` if no explicit namespace is provided (such as :func:`exec` and :func:`eval`). In previous versions, whether or not changes could be accessed by calling :func:`!locals` 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 :func:`!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. :func:`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, :attr:`FrameType.f_locals <frame.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 affected :ref:`Python APIs <pep667-porting-notes-py>` and :ref:`C APIs <pep667-porting-notes-c>`.

(PEP and implementation contributed by Mark Shannon and Tian Gao in :gh:`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 the arm64-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 in :gh:`114099`.)

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

.. seealso:: :pep:`730`, :pep:`738`

Other Language Changes

New Modules

Improved Modules

argparse

array

ast

  • The constructors of node types in the :mod:`ast` module are now stricter in the arguments they accept, with more intuitive behavior when arguments are omitted.

    If an optional field on an AST node is not included as an argument when constructing an instance, the field will now be set to None. Similarly, if a list field is omitted, that field will now be set to an empty list, and if an :class:`!expr_context` field is omitted, it defaults to :class:`Load() <ast.Load>`. (Previously, in all cases, the attribute would be missing on the newly constructed AST node instance.)

    In all other cases, where a required argument is omitted, the node constructor will emit a :exc:`DeprecationWarning`. This will raise an exception in Python 3.15. Similarly, passing a keyword argument to the constructor that does not map to a field on the AST node is now deprecated, and will raise an exception in Python 3.15.

    These changes do not apply to user-defined subclasses of :class:`ast.AST` unless the class opts in to the new behavior by defining the :attr:`.AST._field_types` mapping.

    (Contributed by Jelle Zijlstra in :gh:`105858`, :gh:`117486`, and :gh:`118851`.)

  • :func:`ast.parse` now accepts an optional argument optimize which is passed on to :func:`compile`. This makes it possible to obtain an optimized AST. (Contributed by Irit Katriel in :gh:`108113`.)

asyncio

base64

compileall

concurrent.futures

configparser

  • :class:`~configparser.ConfigParser` now has support for unnamed sections, which allows for top-level key-value pairs. This can be enabled with the new allow_unnamed_section parameter. (Contributed by Pedro Sousa Lacerda in :gh:`66449`.)

copy

ctypes

  • As a consequence of necessary internal refactoring, initialization of internal metaclasses now happens in __init__ rather than in __new__. This affects projects that subclass these internal metaclasses to provide custom initialization. Generally:

    • Custom logic that was done in __new__ after calling super().__new__ should be moved to __init__.
    • To create a class, call the metaclass, not only the metaclass's __new__ method.

    See :gh:`124520` for discussion and links to changes in some affected projects.

  • :class:`ctypes.Structure` objects have a new :attr:`~ctypes.Structure._align_` attribute which allows the alignment of the structure being packed to/from memory to be specified explicitly. (Contributed by Matt Sanderson in :gh:`112433`)

dbm

dis

doctest

email

  • Headers with embedded newlines are now quoted on output. The :mod:`~email.generator` will now refuse to serialize (write) headers that are improperly folded or delimited, such that they would be parsed as multiple headers or joined with adjacent data. If you need to turn this safety feature off, set :attr:`~email.policy.Policy.verify_generated_headers`. (Contributed by Bas Bloemsaat and Petr Viktorin in :gh:`121650`.)
  • :func:`~email.utils.getaddresses` and :func:`~email.utils.parseaddr` now return ('', '') pairs in more situations where invalid email addresses are encountered instead of potentially inaccurate values. The two functions have a new optional strict parameter (default True). To get the old behavior (accepting malformed input), use strict=False. getattr(email.utils, 'supports_strict_parsing', False) can be used to check if the strict parameter is available. (Contributed by Thomas Dwyer and Victor Stinner for :gh:`102988` to improve the :cve:`2023-27043` fix.)

enum

fractions

glob

  • Add :func:`~glob.translate`, a function to convert a path specification with shell-style wildcards to a regular expression. (Contributed by Barney Gale in :gh:`72904`.)

importlib

io

ipaddress

itertools

marshal

  • Add the allow_code parameter in module functions. Passing allow_code=False prevents serialization and de-serialization of code objects which are incompatible between Python versions. (Contributed by Serhiy Storchaka in :gh:`113626`.)

math

  • The new function :func:`~math.fma` performs fused multiply-add operations. This computes x * y + z with only a single round, and so avoids any intermediate loss of precision. It wraps the fma() function provided by C99, and follows the specification of the IEEE 754 "fusedMultiplyAdd" operation for special cases. (Contributed by Mark Dickinson and Victor Stinner in :gh:`73468`.)

mimetypes

mmap

multiprocessing

os

os.path

pathlib

pdb

queue

random

re

shutil

site

sqlite3

ssl

statistics

subprocess

sys

  • Add the :func:`~sys._is_interned` function to test if a string was interned. This function is not guaranteed to exist in all implementations of Python. (Contributed by Serhiy Storchaka in :gh:`78573`.)

tempfile

time

  • On Windows, :func:`~time.monotonic` now uses the QueryPerformanceCounter() clock for a resolution of 1 microsecond, instead of the GetTickCount64() clock which has a resolution of 15.6 milliseconds. (Contributed by Victor Stinner in :gh:`88494`.)
  • On Windows, :func:`~time.time` now uses the GetSystemTimePreciseAsFileTime() clock for a resolution of 1 microsecond, instead of the GetSystemTimeAsFileTime() clock which has a resolution of 15.6 milliseconds. (Contributed by Victor Stinner in :gh:`63207`.)

tkinter

traceback

types

  • :class:`~types.SimpleNamespace` can now take a single positional argument to initialise the namespace's arguments. This argument must either be a mapping or an iterable of key-value pairs. (Contributed by Serhiy Storchaka in :gh:`108191`.)

typing

unicodedata

venv

warnings

xml

zipimport

  • Add support for ZIP64 format files. Everybody loves huge data, right? (Contributed by Tim Hatch in :gh:`94146`.)

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

  • This module is no longer considered :term:`soft deprecated`. While :mod:`argparse` remains preferred for new projects that aren't using a third party command line argument processing library, there are aspects of the way argparse works that mean the lower level optparse module may provide a better foundation for writing argument processing libraries, and for implementing command line applications which adhere more strictly than argparse does to various Unix command line processing conventions that originate in the behaviour of the C :c:func:`!getopt` function . (Contributed by Alyssa Coghlan and Serhiy Storchaka in :gh:`126180`.)

pathlib

  • Remove the ability to use :class:`~pathlib.Path` objects as context managers. This functionality was deprecated and has had no effect since Python 3.9. (Contributed by Barney Gale in :gh:`83863`.)

re

tkinter.tix

  • Remove the :mod:`!tkinter.tix` module, deprecated in Python 3.6. The third-party Tix library which the module wrapped is unmaintained. (Contributed by Zachary Ware in :gh:`75552`.)

turtle

typing

unittest

urllib

webbrowser

New Deprecations

CPython Bytecode Changes

  • The oparg of :opcode:`YIELD_VALUE` is now 1 if the yield is part of a yield-from or await, and 0 otherwise. The oparg of :opcode:`RESUME` was changed to add a bit indicating if the except-depth is 1, which is needed to optimize closing of generators. (Contributed by Irit Katriel in :gh:`111354`.)

C API Changes

New Features

Changed C APIs

Limited C API Changes

Removed C APIs

Deprecated C APIs

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

  • Python.h no longer includes the <ieeefp.h> standard header. It was included for the :c:func:`!finite` function which is now provided by the <math.h> header. It should now be included explicitly if needed. Remove also the HAVE_IEEEFP_H macro. (Contributed by Victor Stinner in :gh:`108765`.)

  • Python.h no longer includes these standard header files: <time.h>, <sys/select.h> and <sys/time.h>. If needed, they should now be included explicitly. For example, <time.h> provides the :c:func:`!clock` and :c:func:`!gmtime` functions, <sys/select.h> provides the :c:func:`!select` function, and <sys/time.h> provides the :c:func:`!futimes`, :c:func:`!gettimeofday` and :c:func:`!setitimer` functions. (Contributed by Victor Stinner in :gh:`108765`.)

  • On Windows, Python.h no longer includes the <stddef.h> standard header file. If needed, it should now be included explicitly. For example, it provides :c:func:`!offsetof` function, and size_t and ptrdiff_t types. Including <stddef.h> explicitly was already needed by all other platforms, the HAVE_STDDEF_H macro is only defined on Windows. (Contributed by Victor Stinner in :gh:`108765`.)

  • If the :c:macro:`Py_LIMITED_API` macro is defined, :c:macro:`!Py_BUILD_CORE`, :c:macro:`!Py_BUILD_CORE_BUILTIN` and :c:macro:`!Py_BUILD_CORE_MODULE` macros are now undefined by <Python.h>. (Contributed by Victor Stinner in :gh:`85283`.)

  • The old trashcan macros Py_TRASHCAN_SAFE_BEGIN and Py_TRASHCAN_SAFE_END were removed. They should be replaced by the new macros Py_TRASHCAN_BEGIN and Py_TRASHCAN_END.

    A tp_dealloc function that has the old macros, such as:

    static void
mytype_dealloc(mytype *p)
{
    PyObject_GC_UnTrack(p);
    Py_TRASHCAN_SAFE_BEGIN(p);
    ...
    Py_TRASHCAN_SAFE_END
}

    should migrate to the new macros as follows:

    static void
mytype_dealloc(mytype *p)
{
    PyObject_GC_UnTrack(p);
    Py_TRASHCAN_BEGIN(p, mytype_dealloc)
    ...
    Py_TRASHCAN_END
}

    Note that Py_TRASHCAN_BEGIN has a second argument which should be the deallocation function it is in. The new macros were added in Python 3.8 and the old macros were deprecated in Python 3.11. (Contributed by Irit Katriel in :gh:`105111`.)

Regression Test Changes