Skip to content

Latest commit

 

History

History
2196 lines (1682 loc) · 89.7 KB

3.11.rst

File metadata and controls

2196 lines (1682 loc) · 89.7 KB

What's New In Python 3.11

Release:|release|
Date: |today|

This article explains the new features in Python 3.11, compared to 3.10.

For full details, see the :ref:`changelog <changelog>`.

Summary -- Release highlights

  • Python 3.11 is between 10-60% faster than Python 3.10. On average, we measured a 1.25x speedup on the standard benchmark suite. See Faster CPython for details.

New syntax features:

  • PEP 654: Exception Groups and except*.

New built-in features:

  • PEP 678: Enriching Exceptions with Notes.

New standard library modules:

  • PEP 680: tomllib — Support for Parsing TOML in the Standard Library.

Interpreter improvements:

  • PEP 657: Include Fine Grained Error Locations in Tracebacks.
  • New :option:`-P` command line option and :envvar:`PYTHONSAFEPATH` environment variable to disable automatically prepending a potentially unsafe path (the working dir or script directory, depending on invocation) to :data:`sys.path`.

New typing features:

  • PEP 646: Variadic generics.
  • PEP 655: Marking individual TypedDict items as required or potentially missing.
  • PEP 673: Self type.
  • PEP 675: Arbitrary literal string type.
  • PEP 681: Data Class Transforms.

Important deprecations, removals or restrictions:

  • PEP 594: Removing dead batteries from the standard library.
  • PEP 624: Remove Py_UNICODE encoder APIs.
  • PEP 670: Convert macros to functions in the Python C API.

New Features

Enhanced error locations in tracebacks

When printing tracebacks, the interpreter will now point to the exact expression that caused the error instead of just the line. For example:

Traceback (most recent call last):
  File "distance.py", line 11, in <module>
    print(manhattan_distance(p1, p2))
          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "distance.py", line 6, in manhattan_distance
    return abs(point_1.x - point_2.x) + abs(point_1.y - point_2.y)
                           ^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'x'

Previous versions of the interpreter would point to just the line making it ambiguous which object was None. These enhanced errors can also be helpful when dealing with deeply nested dictionary objects and multiple function calls,

Traceback (most recent call last):
  File "query.py", line 37, in <module>
    magic_arithmetic('foo')
  File "query.py", line 18, in magic_arithmetic
    return add_counts(x) / 25
           ^^^^^^^^^^^^^
  File "query.py", line 24, in add_counts
    return 25 + query_user(user1) + query_user(user2)
                ^^^^^^^^^^^^^^^^^
  File "query.py", line 32, in query_user
    return 1 + query_count(db, response['a']['b']['c']['user'], retry=True)
                               ~~~~~~~~~~~~~~~~~~^^^^^
TypeError: 'NoneType' object is not subscriptable

as well as complex arithmetic expressions:

Traceback (most recent call last):
  File "calculation.py", line 54, in <module>
    result = (x / y / z) * (a / b / c)
              ~~~~~~^~~
ZeroDivisionError: division by zero

See PEP 657 for more details. (Contributed by Pablo Galindo, Batuhan Taskaya and Ammar Askar in :issue:`43950`.)

Note

This feature requires storing column positions in code objects which may result in a small increase of disk usage of compiled Python files or interpreter memory usage. To avoid storing the extra information and/or deactivate printing the extra traceback information, the :option:`-X` no_debug_ranges command line flag or the :envvar:`PYTHONNODEBUGRANGES` environment variable can be used.

Column information for code objects

The information used by the enhanced traceback feature is made available as a general API that can be used to correlate bytecode instructions with source code. This information can be retrieved using:

The :option:`-X` no_debug_ranges option and the environment variable :envvar:`PYTHONNODEBUGRANGES` can be used to disable this feature.

See PEP 657 for more details. (Contributed by Pablo Galindo, Batuhan Taskaya and Ammar Askar in :issue:`43950`.)

PEP 654: Exception Groups and except*

PEP 654 introduces language features that enable a program to raise and handle multiple unrelated exceptions simultaneously. The builtin types :exc:`ExceptionGroup` and :exc:`BaseExceptionGroup` make it possible to group exceptions and raise them together, and the new :keyword:`except* <except_star>` syntax generalizes :keyword:`except` to match subgroups of exception groups.

See PEP 654 for more details.

(Contributed by Irit Katriel in :issue:`45292`. PEP written by Irit Katriel, Yury Selivanov and Guido van Rossum.)

PEP 678: Exceptions can be enriched with notes

The :meth:`add_note` method was added to :exc:`BaseException`. It can be used to enrich exceptions with context information which is not available at the time when the exception is raised. The notes added appear in the default traceback. See PEP 678 for more details. (Contributed by Irit Katriel in :issue:`45607`.)

New Features Related to Type Hints

This section covers major changes affecting PEP 484 type hints and the :mod:`typing` module.

PEP 646: Variadic generics

PEP 484 introduced :data:`~typing.TypeVar`, enabling creation of generics parameterised with a single type. PEP 646 introduces :data:`~typing.TypeVarTuple`, enabling parameterisation with an arbitrary number of types. In other words, a :data:`~typing.TypeVarTuple` is a variadic type variable, enabling variadic generics. This enables a wide variety of use cases. In particular, it allows the type of array-like structures in numerical computing libraries such as NumPy and TensorFlow to be parameterised with the array shape. Static type checkers will now be able to catch shape-related bugs in code that uses these libraries.

See PEP 646 for more details.

(Contributed by Matthew Rahtz in :issue:`43224`, with contributions by Serhiy Storchaka and Jelle Zijlstra. PEP written by Mark Mendoza, Matthew Rahtz, Pradeep Kumar Srinivasan, and Vincent Siles.)

PEP 655: Marking individual TypedDict items as required or not-required

:data:`~typing.Required` and :data:`~typing.NotRequired` provide a straightforward way to mark whether individual items in a :data:`~typing.TypedDict` must be present. Previously this was only possible using inheritance.

Fields are still required by default, unless the total=False parameter is set. For example, the following specifies a dictionary with one required and one not-required key:

class Movie(TypedDict):
   title: str
   year: NotRequired[int]

m1: Movie = {"title": "Black Panther", "year": 2018}  # ok
m2: Movie = {"title": "Star Wars"}  # ok (year is not required)
m3: Movie = {"year": 2022}  # error (missing required field title)

The following definition is equivalent:

class Movie(TypedDict, total=False):
   title: Required[str]
   year: int

See PEP 655 for more details.

(Contributed by David Foster and Jelle Zijlstra in :issue:`47087`. PEP written by David Foster.)

PEP 673: Self type

The new :data:`~typing.Self` annotation provides a simple and intuitive way to annotate methods that return an instance of their class. This behaves the same as the :data:`~typing.TypeVar`-based approach specified in PEP 484 but is more concise and easier to follow.

Common use cases include alternative constructors provided as classmethods and :meth:`~object.__enter__` methods that return self:

class MyLock:
    def __enter__(self) -> Self:
        self.lock()
        return self

    ...

class MyInt:
    @classmethod
    def fromhex(cls, s: str) -> Self:
        return cls(int(s, 16))

    ...

:data:`~typing.Self` can also be used to annotate method parameters or attributes of the same type as their enclosing class.

See PEP 673 for more details.

(Contributed by James Hilton-Balfe in :issue:`46534`. PEP written by Pradeep Kumar Srinivasan and James Hilton-Balfe.)

PEP 675: Arbitrary literal string type

The new :data:`~typing.LiteralString` annotation may be used to indicate that a function parameter can be of any literal string type. This allows a function to accept arbitrary literal string types, as well as strings created from other literal strings. Type checkers can then enforce that sensitive functions, such as those that execute SQL statements or shell commands, are called only with static arguments, providing protection against injection attacks.

For example, a SQL query function could be annotated as follows:

def run_query(sql: LiteralString) -> ...
    ...

def caller(
    arbitrary_string: str,
    query_string: LiteralString,
    table_name: LiteralString,
) -> None:
    run_query("SELECT * FROM students")       # ok
    run_query(query_string)                   # ok
    run_query("SELECT * FROM " + table_name)  # ok
    run_query(arbitrary_string)               # type checker error
    run_query(                                # type checker error
        f"SELECT * FROM students WHERE name = {arbitrary_string}"
    )

See PEP 675 for more details.

(Contributed by Jelle Zijlstra in :issue:`47088`. PEP written by Pradeep Kumar Srinivasan and Graham Bleaney.)

PEP 681: Data Class Transforms

:data:`~typing.dataclass_transform` may be used to decorate a class, metaclass, or a function that is itself a decorator. The presence of @dataclass_transform() tells a static type checker that the decorated object performs runtime "magic" that transforms a class, giving it :func:`dataclasses.dataclass`-like behaviors.

For example:

# The create_model decorator is defined by a library.
@typing.dataclass_transform()
def create_model(cls: Type[T]) -> Type[T]:
    cls.__init__ = ...
    cls.__eq__ = ...
    cls.__ne__ = ...
    return cls

# The create_model decorator can now be used to create new model
# classes, like this:
@create_model
class CustomerModel:
    id: int
    name: str

c = CustomerModel(id=327, name="John Smith")

See PEP 681 for more details.

(Contributed by Jelle Zijlstra in :gh:`91860`. PEP written by Erik De Bonte and Eric Traut.)

PEP 563 May Not Be the Future

  • PEP 563 Postponed Evaluation of Annotations, __future__.annotations that was planned for this release has been indefinitely postponed. See this message for more information.

Windows py.exe launcher improvements

The copy of :ref:`launcher` included with Python 3.11 has been significantly updated. It now supports company/tag syntax as defined in PEP 514 using the -V:<company>/<tag> argument instead of the limited -x.y argument. This allows launching distributions other than PythonCore, which is the one obtained from python.org.

When using -V: selectors, either company or tag can be omitted, but all installs will be searched. For example, -V:OtherPython/ will select the "best" tag registered for OtherPython, while -V:3.11 or -V:/3.11 will select the "best" distribution with tag 3.11.

When using legacy -x, -x.y, -x-ZZ or -x.y-ZZ arguments, all existing behaviour should be preserved from past versions. Only releases from PythonCore will be selected. However, the -64 suffix now implies "not 32-bit", as there are multiple supported 64-bit platforms. 32-bit runtimes are detected by checking its tag for a -32 suffix. All releases of Python since 3.5 have included this in their 32-bit builds.

Other Language Changes

Other CPython Implementation Changes

New Modules

Improved Modules

asyncio

contextlib

Added non parallel-safe :func:`~contextlib.chdir` context manager to change the current working directory and then restore it on exit. Simple wrapper around :func:`~os.chdir`. (Contributed by Filipe Laíns in :issue:`25625`)

dataclasses

datetime

enum

  • EnumMeta renamed to EnumType (EnumMeta kept as alias).
  • StrEnum added -- enum members are and must be strings.
  • ReprEnum added -- causes only the __repr__ to be modified, not the __str__ nor the __format__.
  • FlagBoundary added -- controls behavior when invalid values are given to a flag.
  • EnumCheck added -- used by verify to ensure various constraints.
  • verify added -- function to ensure given EnumCheck constraints.
  • member added -- decorator to ensure given object is converted to an enum member.
  • nonmember added -- decorator to ensure given object is not converted to an enum member.
  • property added -- use instead of types.DynamicClassAttribute.
  • global_enum added -- enum decorator to adjust __repr__ and __str__ to show members in the global context -- see re.RegexFlag for an example.
  • Flag enhancements: members support length, iteration, and containment checks.
  • Enum/Flag fixes: members are now defined before __init_subclass__ is called; dir() now includes methods, etc., from mixed-in data types.
  • Flag fixes: only primary values (power of two) are considered canonical while composite values (3, 6, 10, etc.) are considered aliases; inverted flags are coerced to their positive equivalent.
  • IntEnum / IntFlag / StrEnum fixes: these now inherit from ReprEnum so the str() output now matches format() output, which is the data types' (so both str(AnIntEnum.ONE) and format(AnIntEnum.ONE) is equal to '1').

fractions

functools

  • :func:`functools.singledispatch` now supports :data:`types.UnionType` and :data:`typing.Union` as annotations to the dispatch argument.:

    >>> from functools import singledispatch
>>> @singledispatch
... def fun(arg, verbose=False):
...     if verbose:
...         print("Let me just say,", end=" ")
...     print(arg)
...
>>> @fun.register
... def _(arg: int | float, verbose=False):
...     if verbose:
...         print("Strength in numbers, eh?", end=" ")
...     print(arg)
...
>>> from typing import Union
>>> @fun.register
... def _(arg: Union[list, set], verbose=False):
...     if verbose:
...         print("Enumerate this:")
...     for i, elem in enumerate(arg):
...         print(i, elem)
...

    (Contributed by Yurii Karabas in :issue:`46014`.)

hashlib

IDLE and idlelib

  • Apply syntax highlighting to .pyi files. (Contributed by Alex Waygood and Terry Jan Reedy in :issue:`45447`.)
  • Include prompts when saving Shell with inputs and outputs. (Contributed by Terry Jan Reedy in :gh:`95191`.)

inspect

locale

math

operator

  • A new function operator.call has been added, such that operator.call(obj, *args, **kwargs) == obj(*args, **kwargs). (Contributed by Antony Lee in :issue:`44019`.)

os

pathlib

re

  • Atomic grouping ((?>...)) and possessive quantifiers (*+, ++, ?+, {m,n}+) are now supported in regular expressions. (Contributed by Jeffrey C. Jacobs and Serhiy Storchaka in :issue:`433030`.)

shutil

socket

sqlite3

sys

sysconfig

  • Three new :ref:`installation schemes <installation_paths>` (posix_venv, nt_venv and venv) were added and are used when Python creates new virtual environments or when it is running from a virtual environment. The first two schemes (posix_venv and nt_venv) are OS-specific for non-Windows and Windows, the venv is essentially an alias to one of them according to the OS Python runs on. This is useful for downstream distributors who modify :func:`sysconfig.get_preferred_scheme`. Third party code that creates new virtual environments should use the new venv installation scheme to determine the paths, as does :mod:`venv`. (Contributed by Miro Hrončok in :issue:`45413`.)

threading

time

  • On Unix, :func:`time.sleep` now uses the clock_nanosleep() or nanosleep() function, if available, which has a resolution of 1 nanosecond (10-9 seconds), rather than using select() which has a resolution of 1 microsecond (10-6 seconds). (Contributed by Benjamin Szőke and Victor Stinner in :issue:`21302`.)
  • On Windows 8.1 and newer, :func:`time.sleep` now uses a waitable timer based on high-resolution timers which has a resolution of 100 nanoseconds (10-7 seconds). Previously, it had a resolution of 1 millisecond (10-3 seconds). (Contributed by Benjamin Szőke, Dong-hee Na, Eryk Sun and Victor Stinner in :issue:`21302` and :issue:`45429`.)

traceback

typing

For major changes, see :ref:`new-feat-related-type-hints-311`.

tkinter

  • Added method info_patchlevel() which returns the exact version of the Tcl library as a named tuple similar to :data:`sys.version_info`. (Contributed by Serhiy Storchaka in :gh:`91827`.)

unicodedata

  • The Unicode database has been updated to version 14.0.0. (Contributed by Benjamin Peterson in :issue:`45190`).

unittest

venv

  • When new Python virtual environments are created, the venv :ref:`sysconfig installation scheme <installation_paths>` is used to determine the paths inside the environment. When Python runs in a virtual environment, the same installation scheme is the default. That means that downstream distributors can change the default sysconfig install scheme without changing behavior of virtual environments. Third party code that also creates new virtual environments should do the same. (Contributed by Miro Hrončok in :issue:`45413`.)

warnings

zipfile

  • Added support for specifying member name encoding for reading metadata in the zipfile's directory and file headers. (Contributed by Stephen J. Turnbull and Serhiy Storchaka in :issue:`28080`.)

fcntl

Optimizations

  • Compiler now optimizes simple C-style formatting with literal format containing only format codes %s, %r and %a and makes it as fast as corresponding f-string expression. (Contributed by Serhiy Storchaka in :issue:`28307`.)
  • "Zero-cost" exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in :issue:`40222`.)
  • Pure ASCII strings are now normalized in constant time by :func:`unicodedata.normalize`. (Contributed by Dong-hee Na in :issue:`44987`.)
  • :mod:`math` functions :func:`~math.comb` and :func:`~math.perm` are now up to 10 times or more faster for large arguments (the speed up is larger for larger k). (Contributed by Serhiy Storchaka in :issue:`37295`.)
  • Dict don't store hash value when all inserted keys are Unicode objects. This reduces dict size. For example, sys.getsizeof(dict.fromkeys("abcdefg")) becomes 272 bytes from 352 bytes on 64bit platform. (Contributed by Inada Naoki in :issue:`46845`.)
  • :mod:`re`'s regular expression matching engine has been partially refactored, and now uses computed gotos (or "threaded code") on supported platforms. As a result, Python 3.11 executes the pyperformance regular expression benchmarks up to 10% faster than Python 3.10.

Faster CPython

CPython 3.11 is on average 25% faster than CPython 3.10 when measured with the pyperformance benchmark suite, and compiled with GCC on Ubuntu Linux. Depending on your workload, the speedup could be up to 10-60% faster.

This project focuses on two major areas in Python: faster startup and faster runtime. Other optimizations not under this project are listed in Optimizations.

Faster Startup

Frozen imports / Static code objects

Python caches bytecode in the :ref:`__pycache__<tut-pycache>` directory to speed up module loading.

Previously in 3.10, Python module execution looked like this:

Read __pycache__ -> Unmarshal -> Heap allocated code object -> Evaluate

In Python 3.11, the core modules essential for Python startup are "frozen". This means that their code objects (and bytecode) are statically allocated by the interpreter. This reduces the steps in module execution process to this:

Statically allocated code object -> Evaluate

Interpreter startup is now 10-15% faster in Python 3.11. This has a big impact for short-running programs using Python.

(Contributed by Eric Snow, Guido van Rossum and Kumar Aditya in numerous issues.)

Faster Runtime

Cheaper, lazy Python frames

Python frames are created whenever Python calls a Python function. This frame holds execution information. The following are new frame optimizations:

  • Streamlined the frame creation process.
  • Avoided memory allocation by generously re-using frame space on the C stack.
  • Streamlined the internal frame struct to contain only essential information. Frames previously held extra debugging and memory management information.

Old-style frame objects are now created only when requested by debuggers or by Python introspection functions such as sys._getframe or inspect.currentframe. For most user code, no frame objects are created at all. As a result, nearly all Python functions calls have sped up significantly. We measured a 3-7% speedup in pyperformance.

(Contributed by Mark Shannon in :issue:`44590`.)

Inlined Python function calls

During a Python function call, Python will call an evaluating C function to interpret that function's code. This effectively limits pure Python recursion to what's safe for the C stack.

In 3.11, when CPython detects Python code calling another Python function, it sets up a new frame, and "jumps" to the new code inside the new frame. This avoids calling the C interpreting function altogether.

Most Python function calls now consume no C stack space. This speeds up most of such calls. In simple recursive functions like fibonacci or factorial, a 1.7x speedup was observed. This also means recursive functions can recurse significantly deeper (if the user increases the recursion limit). We measured a 1-3% improvement in pyperformance.

(Contributed by Pablo Galindo and Mark Shannon in :issue:`45256`.)

PEP 659: Specializing Adaptive Interpreter

PEP 659 is one of the key parts of the faster CPython project. The general idea is that while Python is a dynamic language, most code has regions where objects and types rarely change. This concept is known as type stability.

At runtime, Python will try to look for common patterns and type stability in the executing code. Python will then replace the current operation with a more specialized one. This specialized operation uses fast paths available only to those use cases/types, which generally outperform their generic counterparts. This also brings in another concept called inline caching, where Python caches the results of expensive operations directly in the bytecode.

The specializer will also combine certain common instruction pairs into one superinstruction. This reduces the overhead during execution.

Python will only specialize when it sees code that is "hot" (executed multiple times). This prevents Python from wasting time for run-once code. Python can also de-specialize when code is too dynamic or when the use changes. Specialization is attempted periodically, and specialization attempts are not too expensive. This allows specialization to adapt to new circumstances.

(PEP written by Mark Shannon, with ideas inspired by Stefan Brunthaler. See PEP 659 for more information. Implementation by Mark Shannon and Brandt Bucher, with additional help from Irit Katriel and Dennis Sweeney.)

Operation Form Specialization Operation speedup (up to) Contributor(s)
Binary operations x+x; x*x; x-x; Binary add, multiply and subtract for common types such as int, float, and str take custom fast paths for their underlying types. 10% Mark Shannon, Dong-hee Na, Brandt Bucher, Dennis Sweeney
Subscript a[i]

Subscripting container types such as list, tuple and dict directly index the underlying data structures.

Subscripting custom __getitem__ is also inlined similar to :ref:`inline-calls`.

 10-25% Irit Katriel, Mark Shannon
Store subscript a[i] = z Similar to subscripting specialization above. 10-25% Dennis Sweeney
Calls f(arg) C(arg) Calls to common builtin (C) functions and types such as len and str directly call their underlying C version. This avoids going through the internal calling convention. 20% Mark Shannon, Ken Jin
Load global variable print len The object's index in the globals/builtins namespace is cached. Loading globals and builtins require zero namespace lookups. [1] Mark Shannon
Load attribute o.attr Similar to loading global variables. The attribute's index inside the class/object's namespace is cached. In most cases, attribute loading will require zero namespace lookups. [2] Mark Shannon
Load methods for call o.meth() The actual address of the method is cached. Method loading now has no namespace lookups -- even for classes with long inheritance chains. 10-20% Ken Jin, Mark Shannon
Store attribute o.attr = z Similar to load attribute optimization. 2% in pyperformance Mark Shannon
Unpack Sequence *seq Specialized for common containers such as list and tuple. Avoids internal calling convention. 8% Brandt Bucher
[1]A similar optimization already existed since Python 3.8. 3.11 specializes for more forms and reduces some overhead.
[2]A similar optimization already existed since Python 3.10. 3.11 specializes for more forms. Furthermore, all attribute loads should be sped up by :issue:`45947`.

Misc

  • Objects now require less memory due to lazily created object namespaces. Their namespace dictionaries now also share keys more freely. (Contributed Mark Shannon in :issue:`45340` and :issue:`40116`.)
  • A more concise representation of exceptions in the interpreter reduced the time required for catching an exception by about 10%. (Contributed by Irit Katriel in :issue:`45711`.)

FAQ

Q: How should I write my code to utilize these speedups?

A: You don't have to change your code. Write Pythonic code that follows common best practices. The Faster CPython project optimizes for common code patterns we observe.


Q: Will CPython 3.11 use more memory?

A: Maybe not. We don't expect memory use to exceed 20% more than 3.10. This is offset by memory optimizations for frame objects and object dictionaries as mentioned above.


Q: I don't see any speedups in my workload. Why?

A: Certain code won't have noticeable benefits. If your code spends most of its time on I/O operations, or already does most of its computation in a C extension library like numpy, there won't be significant speedup. This project currently benefits pure-Python workloads the most.

Furthermore, the pyperformance figures are a geometric mean. Even within the pyperformance benchmarks, certain benchmarks have slowed down slightly, while others have sped up by nearly 2x!


Q: Is there a JIT compiler?

A: No. We're still exploring other optimizations.

About

Faster CPython explores optimizations for :term:`CPython`. The main team is funded by Microsoft to work on this full-time. Pablo Galindo Salgado is also funded by Bloomberg LP to work on the project part-time. Finally, many contributors are volunteers from the community.

CPython bytecode changes

Deprecated

Pending Removal in Python 3.12

The following APIs have been deprecated in earlier Python releases, and will be removed in Python 3.12.

Python API:

C API:

Removed

Porting to Python 3.11

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

Changes in the Python API

Build Changes

  • Building Python now requires a C11 compiler. Optional C11 features are not required. (Contributed by Victor Stinner in :issue:`46656`.)

  • Building Python now requires support of IEEE 754 floating point numbers. (Contributed by Victor Stinner in :issue:`46917`.)

  • CPython can now be built with the ThinLTO option via --with-lto=thin. (Contributed by Dong-hee Na and Brett Holman in :issue:`44340`.)

  • libpython is no longer linked against libcrypt. (Contributed by Mike Gilbert in :issue:`45433`.)

  • Building Python now requires a C99 <math.h> header file providing the following functions: copysign(), hypot(), isfinite(), isinf(), isnan(), round(). (Contributed by Victor Stinner in :issue:`45440`.)

  • Building Python now requires a C99 <math.h> header file providing a NAN constant, or the __builtin_nan() built-in function. (Contributed by Victor Stinner in :issue:`46640`.)

  • Building Python now requires support for floating point Not-a-Number (NaN): remove the Py_NO_NAN macro. (Contributed by Victor Stinner in :issue:`46656`.)

  • Freelists for object structs can now be disabled. A new :program:`configure` option :option:`!--without-freelists` can be used to disable all freelists except empty tuple singleton. (Contributed by Christian Heimes in :issue:`45522`.)

  • Modules/Setup and Modules/makesetup have been improved and tied up. Extension modules can now be built through makesetup. All except some test modules can be linked statically into main binary or library. (Contributed by Brett Cannon and Christian Heimes in :issue:`45548`, :issue:`45570`, :issue:`45571`, and :issue:`43974`.)

  • Build dependencies, compiler flags, and linker flags for most stdlib extension modules are now detected by :program:`configure`. libffi, libnsl, libsqlite3, zlib, bzip2, liblzma, libcrypt, Tcl/Tk, and uuid flags are detected by pkg-config (when available). :mod:`tkinter` now requires pkg-config command to detect development settings for Tcl/Tk headers and libraries. (Contributed by Christian Heimes and Erlend Egeberg Aasland in :issue:`45847`, :issue:`45747`, and :issue:`45763`.)

    Note

    Use the environment variables :envvar:`TCLTK_CFLAGS` and :envvar:`TCLTK_LIBS` to manually specify the location of Tcl/Tk headers and libraries. The :program:`configure` options --with-tcltk-includes and --with-tcltk-libs have been removed.

    On RHEL 7 and CentOS 7 the development packages do not provide tcl.pc and tk.pc, use :envvar:`TCLTK_LIBS="-ltk8.5 -ltkstub8.5 -ltcl8.5"`. The directory Misc/rhel7 contains .pc files and instructions how to build Python with RHEL 7's and CentOS 7's Tcl/Tk and OpenSSL.

  • CPython now has PEP 11 tier 3 support for cross compiling to WebAssembly platform wasm32-unknown-emscripten (Python in the browser). The effort is inspired by previous work like Pyodide. Emscripten provides a limited subset of POSIX APIs. Python standard libraries features and modules related to networking, processes, threading, signals, mmap, and users/groups are not available or don't work. (Contributed by Christian Heimes and Ethan Smith in :gh:`84461`, promoted in :gh:`95085`)

  • CPython now has PEP 11 tier 3 support for cross compiling to WebAssembly platform wasm32-unknown-wasi (WebAssembly System Interface). Like on Emscripten, only a subset of Python's standard library is available on WASI. (Contributed by Christian Heimes in :gh:`90473`, promoted in :gh:`95085`)

  • CPython will now use 30-bit digits by default for the Python :class:`int` implementation. Previously, the default was to use 30-bit digits on platforms with SIZEOF_VOID_P >= 8, and 15-bit digits otherwise. It's still possible to explicitly request use of 15-bit digits via either the --enable-big-digits option to the configure script or (for Windows) the PYLONG_BITS_IN_DIGIT variable in PC/pyconfig.h, but this option may be removed at some point in the future. (Contributed by Mark Dickinson in :issue:`45569`.)

  • The :mod:`tkinter` package now requires Tcl/Tk version 8.5.12 or newer. (Contributed by Serhiy Storchaka in :issue:`46996`.)

C API Changes

New Features

Porting to Python 3.11

  • :c:func:`PyErr_SetExcInfo()` no longer uses the type and traceback arguments, the interpreter now derives those values from the exception instance (the value argument). The function still steals references of all three arguments. (Contributed by Irit Katriel in :issue:`45711`.)

  • :c:func:`PyErr_GetExcInfo()` now derives the type and traceback fields of the result from the exception instance (the value field). (Contributed by Irit Katriel in :issue:`45711`.)

  • :c:type:`_frozen` has a new is_package field to indicate whether or not the frozen module is a package. Previously, a negative value in the size field was the indicator. Now only non-negative values be used for size. (Contributed by Kumar Aditya in :issue:`46608`.)

  • :c:func:`_PyFrameEvalFunction` now takes _PyInterpreterFrame* as its second parameter, instead of PyFrameObject*. See PEP 523 for more details of how to use this function pointer type.

  • :c:func:`PyCode_New` and :c:func:`PyCode_NewWithPosOnlyArgs` now take an additional exception_table argument. Using these functions should be avoided, if at all possible. To get a custom code object: create a code object using the compiler, then get a modified version with the replace method.

  • :c:type:`PyCodeObject` no longer has the co_code, co_varnames, co_cellvars and co_freevars fields. Instead, use :c:func:`PyCode_GetCode`, :c:func:`PyCode_GetVarnames`, :c:func:`PyCode_GetCellvars` and :c:func:`PyCode_GetFreevars` respectively to access them via the C API. (Contributed by Brandt Bucher in :issue:`46841` and Ken Jin in :gh:`92154` and :gh:`94936`.)

  • The old trashcan macros (Py_TRASHCAN_SAFE_BEGIN/Py_TRASHCAN_SAFE_END) are now deprecated. 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.

    To support older Python versions in the same codebase, you can define the following macros and use them throughout the code (credit: these were copied from the mypy codebase):

    #if PY_MAJOR_VERSION >= 3 && PY_MINOR_VERSION >= 8
#  define CPy_TRASHCAN_BEGIN(op, dealloc) Py_TRASHCAN_BEGIN(op, dealloc)
#  define CPy_TRASHCAN_END(op) Py_TRASHCAN_END
#else
#  define CPy_TRASHCAN_BEGIN(op, dealloc) Py_TRASHCAN_SAFE_BEGIN(op)
#  define CPy_TRASHCAN_END(op) Py_TRASHCAN_SAFE_END(op)
#endif

  • The :c:func:`PyType_Ready` function now raises an error if a type is defined with the :const:`Py_TPFLAGS_HAVE_GC` flag set but has no traverse function (:c:member:`PyTypeObject.tp_traverse`). (Contributed by Victor Stinner in :issue:`44263`.)

  • Heap types with the :const:`Py_TPFLAGS_IMMUTABLETYPE` flag can now inherit the PEP 590 vectorcall protocol. Previously, this was only possible for :ref:`static types <static-types>`. (Contributed by Erlend E. Aasland in :issue:`43908`)

  • Since :c:func:`Py_TYPE()` is changed to a inline static function, Py_TYPE(obj) = new_type must be replaced with Py_SET_TYPE(obj, new_type): see the :c:func:`Py_SET_TYPE()` function (available since Python 3.9). For backward compatibility, this macro can be used:

    #if PY_VERSION_HEX < 0x030900A4 && !defined(Py_SET_TYPE)
static inline void _Py_SET_TYPE(PyObject *ob, PyTypeObject *type)
{ ob->ob_type = type; }
#define Py_SET_TYPE(ob, type) _Py_SET_TYPE((PyObject*)(ob), type)
#endif

    (Contributed by Victor Stinner in :issue:`39573`.)

  • Since :c:func:`Py_SIZE()` is changed to a inline static function, Py_SIZE(obj) = new_size must be replaced with Py_SET_SIZE(obj, new_size): see the :c:func:`Py_SET_SIZE()` function (available since Python 3.9). For backward compatibility, this macro can be used:

    #if PY_VERSION_HEX < 0x030900A4 && !defined(Py_SET_SIZE)
static inline void _Py_SET_SIZE(PyVarObject *ob, Py_ssize_t size)
{ ob->ob_size = size; }
#define Py_SET_SIZE(ob, size) _Py_SET_SIZE((PyVarObject*)(ob), size)
#endif

    (Contributed by Victor Stinner in :issue:`39573`.)

  • <Python.h> no longer includes the header files <stdlib.h>, <stdio.h>, <errno.h> and <string.h> when the Py_LIMITED_API macro is set to 0x030b0000 (Python 3.11) or higher. C extensions should explicitly include the header files after #include <Python.h>. (Contributed by Victor Stinner in :issue:`45434`.)

  • The non-limited API files cellobject.h, classobject.h, code.h, context.h, funcobject.h, genobject.h and longintrepr.h have been moved to the Include/cpython directory. Moreover, the eval.h header file was removed. These files must not be included directly, as they are already included in Python.h: :ref:`Include Files <api-includes>`. If they have been included directly, consider including Python.h instead. (Contributed by Victor Stinner in :issue:`35134`.)

  • The :c:func:`PyUnicode_CHECK_INTERNED` macro has been excluded from the limited C API. It was never usable there, because it used internal structures which are not available in the limited C API. (Contributed by Victor Stinner in :issue:`46007`.)

  • The following frame functions and type are now directly available with #include <Python.h>, it's no longer needed to add #include <frameobject.h>:

    (Contributed by Victor Stinner in :gh:`93937`.)

  • The :c:type:`PyFrameObject` structure members have been removed from the public C API.

    While the documentation notes that the :c:type:`PyFrameObject` fields are subject to change at any time, they have been stable for a long time and were used in several popular extensions.

    In Python 3.11, the frame struct was reorganized to allow performance optimizations. Some fields were removed entirely, as they were details of the old implementation.

    :c:type:`PyFrameObject` fields:

    The Python frame object is now created lazily. A side effect is that the f_back member must not be accessed directly, since its value is now also computed lazily. The :c:func:`PyFrame_GetBack` function must be called instead.

    Debuggers that accessed the f_locals directly must call :c:func:`PyFrame_GetLocals` instead. They no longer need to call :c:func:`PyFrame_FastToLocalsWithError` or :c:func:`PyFrame_LocalsToFast`, in fact they should not call those functions. The necessary updating of the frame is now managed by the virtual machine.

    Code defining PyFrame_GetCode() on Python 3.8 and older:

    #if PY_VERSION_HEX < 0x030900B1
static inline PyCodeObject* PyFrame_GetCode(PyFrameObject *frame)
{
    Py_INCREF(frame->f_code);
    return frame->f_code;
}
#endif

    Code defining PyFrame_GetBack() on Python 3.8 and older:

    #if PY_VERSION_HEX < 0x030900B1
static inline PyFrameObject* PyFrame_GetBack(PyFrameObject *frame)
{
    Py_XINCREF(frame->f_back);
    return frame->f_back;
}
#endif

    Or use the pythoncapi_compat project to get these two functions on older Python versions.

  • Changes of the :c:type:`PyThreadState` structure members:

    Code defining PyThreadState_GetFrame() on Python 3.8 and older:

    #if PY_VERSION_HEX < 0x030900B1
static inline PyFrameObject* PyThreadState_GetFrame(PyThreadState *tstate)
{
    Py_XINCREF(tstate->frame);
    return tstate->frame;
}
#endif

    Code defining PyThreadState_EnterTracing() and PyThreadState_LeaveTracing() on Python 3.10 and older:

    #if PY_VERSION_HEX < 0x030B00A2
static inline void PyThreadState_EnterTracing(PyThreadState *tstate)
{
    tstate->tracing++;
#if PY_VERSION_HEX >= 0x030A00A1
    tstate->cframe->use_tracing = 0;
#else
    tstate->use_tracing = 0;
#endif
}

static inline void PyThreadState_LeaveTracing(PyThreadState *tstate)
{
    int use_tracing = (tstate->c_tracefunc != NULL || tstate->c_profilefunc != NULL);
    tstate->tracing--;
#if PY_VERSION_HEX >= 0x030A00A1
    tstate->cframe->use_tracing = use_tracing;
#else
    tstate->use_tracing = use_tracing;
#endif
}
#endif

    Or use the pythoncapi_compat project to get these functions on old Python functions.

  • Distributors are encouraged to build Python with the optimized Blake2 library libb2.

  • The :c:member:`PyConfig.module_search_paths_set` field must now be set to 1 for initialization to use :c:member:`PyConfig.module_search_paths` to initialize :data:`sys.path`. Otherwise, initialization will recalculate the path and replace any values added to module_search_paths.

  • :c:func:`PyConfig_Read` no longer calculates the initial search path, and will not fill any values into :c:member:`PyConfig.module_search_paths`. To calculate default paths and then modify them, finish initialization and use :c:func:`PySys_GetObject` to retrieve :data:`sys.path` as a Python list object and modify it directly.

Deprecated

Removed