Newest Python PEPs: Recent Episodes
None
Newest Python Enhancement Proposals (PEPs): Information on new language features and some meta-information like release procedure and schedules.
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.
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.
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).
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.
The current wheel 1.0 specification was written over a decade ago, and has been extremely robust to changes in the Python packaging ecosystem. Previous efforts to improve the wheel specification were deferred to focus on other packaging specifications. Meanwhile, the use of wheels has changed dramatically in the last decade. There have been many requests for new wheel features over the years; however, a fundamental obstacle to evolving the wheel specification has been that there is no defined process for how to handle adding backwards-incompatible features to wheels. Therefore, to enable other PEPs to describe new enhancements to the wheel specification, this PEP prescribes compatibility requirements on future wheel revisions. This PEP does not specify a new wheel revision. The specification of a new wheel format (“Wheel 2.0”) is left to a future PEP.
Since Python 3.11.0, CPython has provided two verifiable digital signatures for all CPython artifacts: PGP and Sigstore.
This PEP proposes disallowing bare except: clauses in Python’s exception-handling syntax. Currently, Python allows catching all exceptions with a bare except: clause, which can lead to overly broad exception handling and mask important errors. This PEP suggests requiring explicit exception types in all except clauses, promoting more precise and intentional error handling.
This PEP proposes a mechanism by which projects hosted on pypi.org can safely host wheel artifacts on external sites other than PyPI. This PEP explicitly does not propose external hosting of projects, packages, or their metadata. That functionality is already available by externally hosting independent package indexes. Because this PEP only provides a mechanism for projects to customize the download URL for specific released wheel artifacts, dependency resolution as already implemented by common installer tools such as pip and uv does not need to change.
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.
Add a new C API to import and export Python integers, int objects: especially PyLongWriter_Create() and PyLong_Export() functions.
This PEP recommends two discrete changes to handling of core metadata by indices, such as PyPI:
This PEP specifies a way for organizations to reserve package name prefixes for future uploads.
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.
This PEP introduces tag strings for custom, repeatable string processing. Tag strings are an extension to f-strings, with a custom function – the “tag” – in place of the f prefix. This function can then provide rich features such as safety checks, lazy evaluation, domain-specific languages (DSLs) for web templating, and more.
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).
This PEP supplements PEP 649 by providing various tweaks and additions to its specification:
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.
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.
Add Py_COMPAT_API_VERSION and Py_COMPAT_API_VERSION_MAX macros to opt-in for planned incompatible C API changes in a C extension. Maintainers can decide when they make their C extension compatible and also decide which future Python version they want to be compatible with.
This PEP proposes a new special form, TypeIs, to allow annotating functions that can be used to narrow the type of a value, similar to the builtin isinstance(). Unlike the existing typing.TypeGuard special form, TypeIs can narrow the type in both the if and else branches of a conditional.
Add a C API to the limited C API to configure the Python initialization. It can be used with the stable ABI.
This PEP proposes a collection of changes related to the upload and distribution of digitally signed attestations and metadata used to verify them on a Python package repository, such as PyPI.
Introduce a standard format for a static description file with build details of Python installations.
This PEP proposes adding Android as a supported platform in CPython. The initial goal is for Android to achieve Tier 3 support in Python 3.13.
Add new convenient C APIs to format a type fully qualified name. No longer format type names differently depending on how types are implemented.
This PEP proposes introducing syntactic sugar f(x=) for the common pattern where a named argument is the same as the name of the variable corresponding to its value f(x=x).
This document proposes a way to complement docstrings to add additional documentation to Python symbols using type annotations with Annotated (in class attributes, function and method parameters, return values, and variables).
This PEP specifies how to write a project’s external, or non-PyPI, build and runtime dependencies in a pyproject.toml file for packaging-related tools to consume.
This PEP specifies a metadata format that can be embedded in single-file Python scripts to assist launchers, IDEs and other external tools which may need to interact with such scripts.
This PEP specifies a format for including 3rd-party dependencies in a single-file Python script.
Extracting a source distribution archive should normally use the data filter added in PEP 706. We clarify details, and specify the behaviour for tools that cannot use the filter directly.
This PEP renames the metadata provided by PEP 658 in both HTML and JSON formats of the Simple API and provides guidelines for both clients and servers in how to handle the renaming.
Modules are currently not directly callable. Classes can define a __call__ method that makes instance objects callable, but defining a similarly named function in the global module scope has no effect, and that function can only be called by importing or referencing it directly as module.__call__. PEP 562 added support for :meth:~object.\_\_getattr\_\_ and :meth:~object.\_\_dir\_\_ for modules, but defining __getattr__ to return a value for __call__ still does not make a module callable.
“Like wheels, but instead of a pre-built python package, it’s a pre-built python interpreter”
This PEP describes a way to record the provenance of installed Python distributions. The record is created by an installer and is available to users in the form of a JSON file provenance_url.json in the .dist-info directory. The mentioned JSON file captures additional metadata to allow recording a URL to a :term:distribution package together with the installed distribution hash. This proposal is built on top of PEP 610 following :ref:its corresponding canonical PyPA spec <packaging:direct-url> and complements direct_url.json with provenance_url.json for when packages are identified by a name, and optionally a version.
Comprehensions are currently compiled as nested functions, which provides isolation of the comprehension's iteration variable, but is inefficient at runtime. This PEP proposes to inline list, dictionary, and set comprehensions into the function where they are defined, and provide the expected isolation by pushing/popping clashing locals on the stack. This change makes comprehensions much faster: up to 2x faster for a microbenchmark of a comprehension alone, translating to an 11% speedup for one sample benchmark derived from real-world code that makes heavy use of comprehensions in the context of doing actual work.
Dependency confusion attacks, in which a malicious package is installed instead of the one the user expected, are an increasingly common supply chain threat. Most such attacks against Python dependencies, including the recent PyTorch incident, occur with multiple package repositories, where a dependency expected to come from one repository (e.g. a custom index) is installed from another (e.g. PyPI).
The extraction methods in :external+py3.11:mod:tarfile gain a filter argument, which allows rejecting files or modifying metadata as the archive is extracted. Three built-in named filters are provided, aimed at limiting features that might be surprising or dangerous. These can be used as-is, or serve as a base for custom filters.
This PEP recommends that package installers like pip require a virtual environment by default on Python 3.13+.
CPython's global interpreter lock ("GIL") prevents multiple threads from executing Python code at the same time. The GIL is an obstacle to using multi-core CPUs from Python efficiently. This PEP proposes adding a build configuration (--without-gil) to CPython to let it run Python code without the global interpreter lock and with the necessary changes needed to make the interpreter thread-safe.
This PEP adds an @typing.deprecated() decorator that marks a class or function as deprecated, enabling static checkers to warn when it is used.
This document proposes to lift some of the restrictions originally formulated in PEP 498 and to provide a formalized grammar for f-strings that can be integrated into the parser directly. The proposed syntactic formalization of f-strings will have some small side-effects on how f-strings are parsed and interpreted, allowing for a considerable number of advantages for end users and library developers, while also dramatically reducing the maintenance cost of the code dedicated to parsing f-strings.
This document describes the schedule and other details of the December 2022 election for the Python steering council, as specified in PEP 13. This is the steering council election for the 2023 term (i.e. Python 3.12).
PEP 691 defined a JSON form for the "Simple Repository API". This allowed clients to more easily query the data that was previously only available in HTML, as defined in PEP 503.
PEP 509 introduced a private ma_version_tag field for dictionaries to allow optimizations in CPython and extension libraries. This PEP proposes to rescind PEP 509 and declare the field an implementation detail, as it has already been superseded by alternatives. This will further allow the field to be reused for future optimization.
This PEP proposes adding an @override decorator to the Python type system. This will allow type checkers to prevent a class of bugs that occur when a base class changes methods that are inherited by derived classes.
Add limited C API for extending types whose struct is opaque, by allowing code to only deal with data specific to a particular (sub)class.
This PEP introduces the concept of type defaults for TypeVarLikes (TypeVar, ParamSpec and TypeVarTuple), which act as defaults for a type parameter when none is specified.
This PEP specifies an improved syntax for specifying type parameters within a generic class, function, or type alias. It also introduces a new statement for declaring type aliases.
There is currently no standardized API for uploading files to a Python package repository such as PyPI. Instead, everyone has been forced to reverse engineer the non-standard API from PyPI.
Currently kwargs can be type hinted as long as all of the keyword arguments specified by them are of the same type. However, that behaviour can be very limiting. Therefore, in this PEP we propose a new way to enable more precise kwargs typing. The new approach revolves around using TypedDict to type **kwargs that comprise keyword arguments of different types. It also involves introducing a grammar change and a new dunder __typing_unpack__.
This document describes the development and release schedule for Python 3.12. The schedule primarily concerns itself with PEP-sized items.
The "Simple Repository API" that was defined in PEP 503 (and was in use much longer than that) has served us reasonably well for a very long time. However, the reliance on using HTML as the data exchange mechanism has several shortcomings.
This PEP proposes a feature to transparently defer the execution of imported modules until the moment when an imported object is first used. Since Python programs commonly import many more modules than a single invocation of the program is likely to use in practice, lazy imports can greatly reduce the overall number of modules loaded, improving startup time and memory usage. Lazy imports also mostly eliminate the risk of import cycles.
This PEP proposes a mechanism for Python code to inspect whether a type supports the C-level buffer protocol. This allows type checkers to evaluate whether objects implement the protocol.