Welcome to Python.org @python.org.web.brid.gy

PEP 811: Defining Python Security Response Team membership and responsibilities This PEP proposes formalizing the membership and responsibilities policies of the Python Security Response Team (PSRT). The PSRT is a “highly trusted cabal of Python developers” which handles security vulnerability disclosures to the security@python.org mailing list.

22.10.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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).

21.10.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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

02.10.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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).

19.09.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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’.

08.08.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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

21.07.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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:

19.07.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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/provides once installed. A new key named import-names will be added to the [project] table in pyproject.toml for providing the values for the new core metadata field. This also leads to the introduction of core metadata version 2.5.

05.06.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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.

23.05.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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().

12.05.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

PEP 790: Python 3.15 Release Schedule This document describes the development and release schedule for Python 3.15.

26.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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:

23.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

PEP 787: Safer subprocess usage using t-strings PEP 750 introduced template strings (t-strings) as a generalization of f-strings, providing a way to safely handle string interpolation in various contexts. This PEP proposes extending the subprocess and shlex modules to natively support t-strings, enabling safer and more ergonomic shell command execution with interpolated values, as well as serving as a reference implementation for the t-string feature to improve API ergonomics.

13.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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:

08.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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.* package.

06.04.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

PEP 783: Emscripten Packaging This PEP proposes a new platform tag series pyodide for binary Python package distributions for the Pyodide Python runtime.

28.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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

27.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

PEP 781: Make ``TYPE_CHECKING`` a built-in constant This PEP proposes adding a new built-in variable, TYPE_CHECKING, to improve the experience of writing Python code with type annotations. It is evaluated as True when the code is being analyzed by a static type checker, and as False during normal runtime execution. Unlike typing.TYPE_CHECKING, which this variable replaces, it does not require an import statement.

24.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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 interpreter. For this, it defines a set of ABI Features and specifies how they are made available via an addition to the Python Standard Library in the form of a new attribute sys.abi_features, as well as for environment markers as a new marker variable, sys_abi_features.

21.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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.

18.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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 make the free-threaded build the default. Because of the number of unknowns at the time, the criteria for moving to the next phase were left deliberately vague at the time. This PEP establishes clear expectations and requirements for moving to Phase II, making the free-threaded Python build officially supported.

13.03.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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.

24.02.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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 are predefined, architecture-specific templates that are used to generate machine code at runtime.

27.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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 ability to manage releases for many years to come.

21.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

PEP 771: Default Extras for Python Software Packages PEP 508 specifies a mini-language for declaring package dependencies. One feature of this language is the ability to specify extras, which are optional components of a distribution that, when used, install additional dependencies. This PEP proposes a mechanism to allow one or more extras to be installed by default if none are provided explicitly.

13.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

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.

02.01.2025 00:00 — 👍 0 🔁 0 💬 0 📌 0

PEP 769: Add a 'default' keyword argument to 'attrgetter', 'itemgetter' and 'getitem' This proposal aims to enhance the operator module by adding a default keyword argument to the attrgetter, itemgetter and getitem functions. This addition would allow these functions to return a specified default value when the targeted attribute or item is missing, thereby preventing exceptions and simplifying code that handles optional attributes or items.

22.12.2024 00:00 — 👍 0 🔁 0 💬 0 📌 0

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.

25.11.2024 00:00 — 👍 0 🔁 0 💬 0 📌 0

PEP 767: Annotating Read-Only Attributes PEP 705 introduced the typing.ReadOnly type qualifier to allow defining read-only typing.TypedDict items.

18.11.2024 00:00 — 👍 0 🔁 0 💬 0 📌 0

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.

15.11.2024 00:00 — 👍 0 🔁 0 💬 0 📌 0

Latest posts by python.org.web.brid.gy on Bluesky