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

PEP 743: Add Py_COMPAT_API_VERSION to the Python C API
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. ⌘ Read more

PEP 742: Narrowing types with TypeNarrower
This PEP proposes a new special form, TypeNarrower, 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, TypeNarrower can narrow the type in both the if and else branches of a conditional. ⌘ Read more

PEP 741: Python Configuration C API
Add a C API to the limited C API to configure the Python preinitialization and initialization, and to get the current configuration. It can be used with the stable ABI. ⌘ Read more

PEP 738: Adding Android as a supported platform
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. ⌘ Read more

PEP 737: Unify type name formatting
Add new convenient APIs to format type names the same way in Python and in C. No longer format type names differently depending on how types are implemented. Also, put an end to truncating type names in C. The new C API is compatible with the limited C API. ⌘ Read more

PEP 734: Multiple Interpreters in the Stdlib
This PEP proposes to add a new module, interpreters, to support inspecting, creating, and running code in multiple interpreters in the current process. This includes Interpreter objects that represent the underlying interpreters. The module will also provide a basic Queue class for communication between interpreters. Finally, we will add a new concurrent.futures.InterpreterPoolExecutor based on the interpreters module. ⌘ Read more

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

PEP 732: The Python Documentation Editorial Board
This PEP: ⌘ Read more

PEP 730: Adding iOS as a supported platform
This PEP proposes adding iOS as a supported platform in CPython. The initial goal is to achieve Tier 3 support for Python 3.13. This PEP describes the technical aspects of the changes that are required to support iOS. It also describes the project management concerns related to adoption of iOS as a Tier 3 platform. ⌘ Read more

PEP 729: Typing governance process
This PEP proposes a new way to govern the Python type system: a council that is responsible for maintaining and developing the Python type system. The council will maintain a specification and conformance test suite and will initially be appointed by the Python Steering Council. ⌘ Read more

PEP 727: Documentation Metadata in Typing
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). ⌘ Read more

PEP 725: Specifying external dependencies in pyproject.toml
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. ⌘ Read more

PEP 723: Embedding pyproject.toml in single-file scripts
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. ⌘ Read more

PEP 722: Dependency specification for single-file scripts
This PEP specifies a format for including 3rd-party dependencies in a single-file Python script. ⌘ Read more

PEP 721: Using tarfile.data_filter for source distribution extraction
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. ⌘ Read more

PEP 714: Rename dist-info-metadata in the Simple API
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. ⌘ Read more

PEP 713: Callable Modules
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 callab … ⌘ Read more

PEP 711: PyBI: a standard format for distributing Python Binaries
“Like wheels, but instead of a pre-built python package, it’s a pre-built python interpreter” ⌘ Read more

PEP 710: Recording the provenance of installed packages
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 … ⌘ Read more`

PEP 709: Inlined comprehensions
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 … ⌘ Read more

PEP 708: Extending the Repository API to Mitigate Dependency Confusion Attacks
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). ⌘ Read more

PEP 706: Filter for tarfile.extractall
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. ⌘ Read more

PEP 704: Require virtual environments by default for package installers
This PEP recommends that package installers like pip require a virtual environment by default on Python 3.13+. ⌘ Read more

PEP 703: Making the Global Interpreter Lock Optional in CPython
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. ⌘ Read more

PEP 702: Marking deprecations using the type system
This PEP adds an @typing.deprecated() decorator that marks a class or function as deprecated, enabling static checkers to warn when it is used. ⌘ Read more

PEP 701: Syntactic formalization of f-strings
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- … ⌘ Read more

PEP 8104: 2023 Term Steering Council election
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). ⌘ Read more

PEP 700: Additional Fields for the Simple API for Package Indexes
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. ⌘ Read more

PEP 699: Remove private dict version field added in PEP 509
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. ⌘ Read more

PEP 698: Override Decorator for Static Typing
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. ⌘ Read more

PEP 697: C API for Extending Opaque Types
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. ⌘ Read more

PEP 696: Type defaults for TypeVarLikes
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. ⌘ Read more

PEP 693: Python 3.12 Release Schedule
This document describes the development and release schedule for Python 3.12. The schedule primarily concerns itself with PEP-sized items. ⌘ Read more

PEP 691: JSON-based Simple API for Python Package Indexes
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. ⌘ Read more

PEP 690: Lazy Imports
This PEP proposes a feature to transparently defer the execution of imported modules until the moment when an imported object is 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. ⌘ Read more

PEP 688: Making the buffer protocol accessible in Python
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. ⌘ Read more

PEP 687: Isolating modules in the standard library
Extensions in the standard library will be converted to multi-phase initialization (PEP 489) and where possible, all state will be stored on module objects rather than in process-global variables. ⌘ Read more

PEP 686: Make UTF-8 mode default
This PEP proposes enabling UTF-8 mode by default. ⌘ Read more

PEP 685: Comparison of extra names for optional distribution dependencies
This PEP specifies how to normalize distribution _extra_
names when performing comparisons.
This prevents tools from either failing to find an extra name or
accidentally matching against an unexpected name. ⌘ Read more

PEP 683: Immortal Objects, Using a Fixed Refcount
Under this proposal, any object may be marked as immortal.
“Immortal” means the object will never be cleaned up (at least until
runtime finalization). Specifically, the refcount for an immortal
object is set to a sentinel value, and that refcount is never changed
by Py_INCREF(), Py_DECREF(), or Py_SET_REFCNT().
For immortal containers, the PyGC_Head is never
changed by the garbage collector. ⌘ Read more

PEP 682: Format Specifier for Signed Zero
Though float and Decimal types can represent signed zero, in many
fields of mathematics negative zero is surprising or unwanted – especially
in the context of displaying an (often rounded) numerical result. This PEP
proposes an extension to the string format specification allowing negative
zero to be normalized to positive zero. ⌘ Read more

PEP 679: Allow parentheses in assert statements
This pep proposes to allow parentheses surrounding the two-subject form of
assert statements. This will cause the interpreter to reinterpret what before
would have been an assert with a two-element tuple that will always be True
(assert (expression, message)) to an assert statement with a subject and a
failure message, equivalent to the statement with the parentheses removed
(assert expression, message). ⌘ Read more

PEP 678: Enriching Exceptions with Notes
Exception objects are typically initialized with a message that describes the
error which has occurred. Because further information may be available when the
exception is caught and re-raised, this PEP proposes to add a .__note__
attribute and update the builtin traceback formatting code to include it in
the formatted traceback following the exception string. ⌘ Read more

PEP 677: Callable Type Syntax
This PEP introduces a concise and friendly syntax for callable types,
supporting the same functionality as typing.Callable but with an
arrow syntax inspired by the syntax for typed function
signatures. This allows types like Callable[[int, str], bool] to
be written (int, str) -> bool. ⌘ Read more

PEP 674: Disallow using macros as l-value
Incompatible C API change disallowing using macros as l-value to allow
evolving CPython internals and to ease the C API implementation on other
Python implementation. ⌘ Read more

PEP 673: Self Type
This PEP introduces a simple and intuitive way to annotate methods that return
an instance of their class. This behaves the same as the TypeVar-based
approach specified in PEP 484
but is more concise and easier to follow. ⌘ Read more

PEP 672: Unicode-related Security Considerations for Python
This document explains possible ways to misuse Unicode to write Python
programs that appear to do something else than they actually do. ⌘ Read more

PEP 671: Syntax for late-bound function argument defaults
Function parameters can have default values which are calculated during
function definition and saved. This proposal introduces a new form of
argument default, defined by an expression to be evaluated at function
call time. ⌘ Read more

PEP 670: Convert macros to functions in the Python C API
Convert macros to static inline functions or regular functions. ⌘ Read more

PEP 8103: 2022 Term steering council election
This document describes the schedule and other details of the December
2021 election for the Python steering council, as specified in
PEP 13. This is the steering council election for the 2022 term
(i.e. Python 3.11). ⌘ Read more