PEP 833: Freezing the HTML simple repository API
This PEP proposes freezing the standard HTML representation of the simple repository API, as originally specified in PEP 503 and updated over subsequent PEPs. ⌘ Read more

PEP 829: Structured Startup Configuration via .site.toml Files
This PEP proposes a TOML-based configuration file format to replace the .pth file mechanism used by site.py during interpreter startup. The new format, using files named .site.toml, provides structured configuration for extending sys.path and executing package initialization code, replacing the current ad-hoc .pth format that conflates path configuration with arbitrary code execution. ⌘ Read more

PEP 828: Supporting ‘yield from’ in asynchronous generators
This PEP introduces support for yield from in an asynchronous generator function. ⌘ Read more

PEP 827: Type Manipulation
We propose to add powerful type-level introspection and construction facilities to the type system, inspired in large part by TypeScript’s conditional and mapped types, but adapted to the quite different conditions of Python typing. ⌘ Read more

PEP 826: Python 3.16 Release Schedule
This document describes the development and release schedule for Python 3.16. ⌘ Read more

PEP 821: Support for unpacking TypedDicts in Callable type hints
This PEP proposes allowing Unpack[TypedDict] in the parameter list inside Callable, enabling concise and type-safe ways to describe keyword-only callable signatures. Currently, Callable assumes positional-only parameters, and typing keyword-only functions requires verbose callback protocols. With this proposal, the keyword structure defined by a TypedDict can be reused directly in Callable. ⌘ Read more

PEP 819: JSON Package Metadata
This PEP proposes introducing JSON encoded core metadata and wheel file format metadata files in Python packages. Python package metadata (“core metadata”) was first defined in PEP 241 to use RFC 822 email headers to encode information about packages. This was reasonable in 2001; email messages were the only widely used, standardized text format that had a parser in the standard library. However, issues with handling different encodings, differing handling of line breaks, and other differences between i … ⌘ Read more

PEP 815: Deprecate RECORD.jws and RECORD.p7s
This PEP deprecates the RECORD.jws and RECORD.p7s wheel signature files. Lack of support in tooling means that these virtually unused files do not provide the security they purport. Users looking for wheel signing should instead refer to index hosted attestations. ⌘ Read more

PEP 814: Add frozendict built-in type
A new public immutable type frozendict is added to the builtins module. ⌘ Read more

PEP 8107: 2026 Term Steering Council election
This document describes the schedule and other details of the 2025 election for the Python steering council, as specified in PEP 13. This is the steering council election for the 2026 term (i.e. Python 3.15). ⌘ Read more

PEP 810: Explicit lazy imports
This PEP introduces syntax for lazy imports as an explicit language feature: ⌘ Read more

PEP 809: Stable ABI for the Future
The Stable ABI as abi3 can no longer be preserved, and requires replacement. abi2026 will be the first replacement, providing resolution of current known incompatibilities, with planned retirement after at least 10 years. The next ABI (for example, abi2031) will have at least five years of overlap with the preceding one. ⌘ Read more

PEP 807: Index support for Trusted Publishing
This PEP proposes a standard mechanism through which arbitrary Python package indices can support “Trusted Publishing,” a misuse-resistant credential exchange scheme already implemented by the Python Package Index (PyPI). ⌘ Read more

PEP 806: Mixed sync/async context managers with precise async marking
Python allows the with and async with statements to handle multiple context managers in a single statement, so long as they are all respectively synchronous or asynchronous. When mixing synchronous and asynchronous context managers, developers must use deeply nested statements or use risky workarounds such as overuse of AsyncExitStack. ⌘ Read more

PEP 804: An external dependency registry and name mapping mechanism
This PEP specifies a name mapping mechanism that allows packaging tools to map external dependency identifiers (as introduced in PEP 725) to their counterparts in other package repositories. ⌘ Read more

PEP 803: Stable ABI for Free-Threaded Builds
Version 3.15 of the Stable ABI will be compatible with both free-threaded and GIL-enabled builds. To allow this, the PyObject internal structure and related APIs will be removed from version 3.15 of the Limited API, requiring migration to new API for common tasks like defining modules and most classes. ⌘ Read more

PEP 802: Display Syntax for the Empty Set
We propose a new notation, {/}, to construct and represent the empty set. This is modelled after the corresponding mathematical symbol ‘\emptyset’. ⌘ Read more

PEP 799: A dedicated profiling package for organizing Python profiling tools
This PEP proposes the creation of a new standard library module named profiling to organize Python’s built-in profiling tools under a single, coherent namespace. ⌘ Read more

PEP 800: Disjoint bases in the type system
To analyze Python programs precisely, type checkers need to know when two classes can and cannot have a common child class. However, the information necessary to determine this is not currently part of the type system. This PEP adds a new decorator, @typing.disjoint_base, that indicates that a class is a “disjoint base”. Two classes that have distinct, unrelated disjoint bases cannot have a common child class. ⌘ Read more

PEP 798: Unpacking in Comprehensions
This PEP proposes extending list, set, and dictionary comprehensions, as well as generator expressions, to allow unpacking notation (* and **) at the start of the expression, providing a concise way of combining an arbitrary number of iterables into one list or set or generator, or an arbitrary number of dictionaries into one dictionary, for example: ⌘ Read more

PEP 794: Import Name Metadata
This PEP proposes extending the core metadata specification for Python packaging to include a new, repeatable field named Import-Name to record the import names that a project owns once installed. A new key named import-names will be added to the [project] table in pyproject.toml. This also leads to the introduction of core metadata version 2.5. ⌘ Read more

PEP 793: PyModExport: A new entry point for C extension modules
In this PEP, we propose a new entry point for C extension modules, by which one can define a module using an array of PyModuleDef_Slot structures without an enclosing PyModuleDef structure. This allows extension authors to avoid using a statically allocated PyObject, lifting the most common obstacle to making one compiled library file usable with both regular and free-threaded builds of CPython. ⌘ Read more

PEP 791: imath — module for integer-specific mathematics functions
This PEP proposes a new module for number-theoretical, combinatorial and other functions defined for integer arguments, like math.gcd() or math.isqrt(). ⌘ Read more

PEP 788: Reimagining native threads
PyGILState_Ensure(), PyGILState_Release(), and other related functions in the PyGILState family are the most common way to create native threads that interact with Python. They have been the standard for over twenty years (PEP 311). But, over time, these functions have become problematic: ⌘ Read more

PEP 785: New methods for easier handling of ExceptionGroup\ s
As PEP 654 ExceptionGroup has come into widespread use across the Python community, some common but awkward patterns have emerged. We therefore propose adding two new methods to exception objects: ⌘ Read more

PEP 784: Adding Zstandard to the standard library
Zstandard is a widely adopted, mature, and highly efficient compression standard. This PEP proposes adding a new module to the Python standard library containing a Python wrapper around Meta’s zstd library, the default implementation. Additionally, to avoid name collisions with packages on PyPI and to present a unified interface to Python users, compression modules in the standard library will be moved under a compression.* namespace package. ⌘ Read more

PEP 782: Add PyBytesWriter C API
Add a new PyBytesWriter C API to create bytes objects. ⌘ Read more

PEP 780: ABI features as environment markers
This PEP defines using ABI features as environment markers for project dependencies, through a new sys_abi_features environment marker and sys.abi_features attribute in the sys module. PEP 508 (later moved to packaging:dependency-specifiers) introduced environment markers to specify dependencies based on rules that describe when the dependency should be used. This PEP extends the environment markers to allow specifying dependencies based on specific ABI features of the Python interprete … ⌘ Read more

PEP 776: Emscripten Support
Emscripten is a complete open source compiler toolchain. It compiles C/C++ code into WebAssembly/JavaScript executables, for use in JavaScript runtimes, including browsers and Node.js. The Rust language also maintains an Emscripten target. ⌘ Read more

PEP 779: Criteria for supported status for free-threaded Python
The acceptance of PEP 703 (Making the Global Interpreter Lock Optional in CPython), as announced by the Steering Council, describes three phases of development for the work to remove the Global Interpreter Lock. Phase I started early in the development of Python 3.13, and includes making the free-threaded (GIL-less) Python build available but explicitly experimental. Phase II would make the free-threaded build officially supported but still optional, and phase III would … ⌘ Read more

PEP 775: Make zlib required to build CPython
Building CPython without the zlib compression library will no be longer supported, and the zlib module will be required in the standard library. The only exception is WASI, as zlib is not currently supported in CPython on WASI. Building the interpreter without zlib may still be possible, but formally unsupported. ⌘ Read more

PEP 774: Removing the LLVM requirement for JIT builds
Since Python 3.13, CPython has been able to be configured and built with an experimental just-in-time (JIT) compiler via the –enable-experimental-jit flag on Linux and Mac and –experimental-jit on Windows. To build CPython with the JIT enabled, users are required to have LLVM installed on their machine (initially, with LLVM 16 but more recently, with LLVM 19). LLVM is responsible for generating stencils that are essential to our copy-and-patch JIT (see PEP 744). These stencils a … ⌘ Read more

PEP 773: A Python Installation Manager for Windows
Installation of the python.org Python distribution on Windows is complex. There are three main approaches with roughly equivalent levels of user experience, and yet all of these suffer from different limitations, including failing to satisfy modern usage scenarios. This PEP proposes a design for a single Windows install workflow tool that satisfies all the needs of the existing installers for the platform, while avoiding most of their limitations, and provides the core team with the … ⌘ Read more

PEP 770: Improving measurability of Python packages with Software Bill-of-Materials
Software Bill-of-Materials (SBOM) is a technology-and-ecosystem-agnostic method for describing software composition, provenance, heritage, and more. SBOMs are used as inputs for software composition analysis (SCA) tools, such as scanners for vulnerabilities and licenses, and have been gaining traction in global software regulations and frameworks. ⌘ Read more

PEP 768: Safe external debugger interface for CPython
This PEP proposes adding a zero-overhead debugging interface to CPython that allows debuggers and profilers to safely attach to running Python processes. The interface provides safe execution points for attaching debugger code without modifying the interpreter’s normal execution path or adding runtime overhead. ⌘ Read more

PEP 766: Explicit Priority Choices Among Multiple Indexes
Package resolution is a key part of the Python user experience as the means of extending Python’s core functionality. The experience of package resolution is mostly taken for granted until someone encounters a situation where the package installer does something they don’t expect. The installer behavior with multiple indexes has been a common source of unexpected behavior. Through its ubiquity, pip has long defined the standard expected behavior across other tools in the ecosy … ⌘ Read more

PEP 765: Disallow return/break/continue that exit a finally block
This PEP proposes to withdraw support for return, break and continue statements that break out of a finally block. This was proposed in the past by PEP 601. The current PEP is based on empirical evidence regarding the cost/benefit of this change, which did not exist at the time that PEP 601 was rejected. It also proposes a slightly different solution than that which was proposed by PEP 601. ⌘ Read more

PEP 763: Limiting deletions on PyPI
We propose limiting when users can delete files, releases, and projects from PyPI. A project, release, or file may only be deleted within 72 hours of when it is uploaded to the index. From this point, users may only use the “yank” mechanism specified by PEP 592. ⌘ Read more

PEP 8106: 2025 Term Steering Council election
This document describes the schedule and other details of the 2024 election for the Python steering council, as specified in PEP 13. This is the steering council election for the 2025 term (i.e. Python 3.14). ⌘ Read more

PEP 762: REPL-acing the default REPL
One of Python’s core strengths is its interactive mode, also known as the Read-Eval-Print Loop (REPL), or the Python console, or the Python shell. This PEP describes the new implementation of this functionality written in Python. The new REPL released in Python 3.13 aims to provide modern features expected by today’s users, such as multi-line editing, syntax highlighting, custom commands, and an overall improved interactive experience. ⌘ Read more

PEP 761: Deprecating PGP signatures for CPython artifacts
Since Python 3.11.0, CPython has provided two verifiable digital signatures for all CPython artifacts: PGP and Sigstore. ⌘ Read more

PEP 758: Allow except and except* expressions without parentheses
This PEP 1 proposes to allow unparenthesized except and except* blocks in Python’s exception handling syntax. Currently, when catching multiple exceptions, parentheses are required around the exception types. This was a Python 2 remnant. This PEP suggests allowing the omission of these parentheses, simplifying the syntax, making it more consistent with other parts of the syntax that make parentheses optional, and improving readability in certain cases. ⌘ Read more

PEP 756: Add PyUnicode_Export() and PyUnicode_Import() C functions
Add functions to the limited C API version 3.14: ⌘ Read more

PEP 755: Implicit namespace policy for PyPI
This PEP codifies an implementation of PEP 752 for PyPI 1. ⌘ Read more

PEP 752: Package repository namespaces
This PEP specifies a way for organizations to reserve package name prefixes for future uploads. ⌘ Read more

PEP 751: A file format to list Python dependencies for installation reproducibility
This PEP proposes a new file format for dependency specification to enable reproducible installation in a Python environment. The format is designed to be human-readable and machine-generated. Installers consuming the file should be able to evaluate each package in question in isolation, with no need for dependency resolution at install-time. ⌘ Read more

PEP 2026: Calendar versioning for Python
This PEP proposes updating the versioning scheme for Python to include the calendar year. This aims to make the support lifecycle clear by making it easy to see when a version was first released, and easier to work out when it will reach end of life (EOL). ⌘ Read more

PEP 746: Type checking Annotated metadata
This PEP proposes a mechanism for type checking metadata that uses the typing.Annotated type. Metadata objects that implement the new __supports_type__ protocol will be type checked by static type checkers to ensure that the metadata is valid for the given type. ⌘ Read more

PEP 745: Python 3.14 Release Schedule
This document describes the development and release schedule for Python 3.14. ⌘ Read more

PEP 744: JIT Compilation
Earlier this year, an experimental “just-in-time” compiler was merged into CPython’s main development branch. While recent CPython releases have included other substantial internal changes, this addition represents a particularly significant departure from the way CPython has traditionally executed Python code. As such, it deserves wider discussion. ⌘ Read more