# Twtxt is an open, distributed microblogging platform that
# uses human-readable text files, common transport protocols,
# and free software.
#
# Learn more about twtxt at  https://github.com/buckket/twtxt
#
# This is an automated Yarn.social feed running feeds v0.1.0@72e53a9
# Learn more about Yarn.social at https://yarn.social
#
# nick        = newest_python_peps
# url         = https://feeds.twtxt.net/newest_python_peps/twtxt.txt
# type        = rss
# source      = https://www.python.org/dev/peps/peps.rss/
# avatar      = 
# description = 
# updated_at  = 2024-12-09T00:24:44Z
#
2020-07-09T01:53:51Z	PEP 625: File name of a Source Distribution ⌘ http://www.python.org/dev/peps/pep-0625
2020-07-09T01:53:51Z	PEP 624: Remove Py_UNICODE encoder APIs ⌘ http://www.python.org/dev/peps/pep-0624
2020-07-09T01:53:51Z	PEP 623: Remove wstr from Unicode ⌘ http://www.python.org/dev/peps/pep-0623
2020-07-09T01:53:51Z	PEP 622: Structural Pattern Matching ⌘ http://www.python.org/dev/peps/pep-0622
2020-07-09T01:53:51Z	PEP 621: Storing project metadata in pyproject.toml ⌘ http://www.python.org/dev/peps/pep-0621
2020-07-09T01:53:51Z	PEP 620: Hide implementation details from the C API ⌘ http://www.python.org/dev/peps/pep-0620
2020-07-09T01:53:51Z	PEP 619: Python 3.10 Release Schedule ⌘ http://www.python.org/dev/peps/pep-0619
2020-07-09T01:53:51Z	PEP 618: Add Optional Length-Checking To zip ⌘ http://www.python.org/dev/peps/pep-0618
2020-07-09T01:53:51Z	PEP 617: New PEG parser for CPython ⌘ http://www.python.org/dev/peps/pep-0617
2020-07-09T01:53:51Z	PEP 616: String methods to remove prefixes and suffixes ⌘ http://www.python.org/dev/peps/pep-0616
2020-07-16T00:00:00Z	PEP 629: Versioning PyPI's Simple API ⌘ http://www.python.org/dev/peps/pep-0629
2020-08-25T00:00:00Z	PEP 630: Isolating Extension Modules ⌘ http://www.python.org/dev/peps/pep-0630
2020-09-03T00:00:00Z	PEP 632: Deprecate distutils module ⌘ http://www.python.org/dev/peps/pep-0632
2020-09-24T00:00:00Z	PEP 638: Syntactic Macros ⌘ http://www.python.org/dev/peps/pep-0638
2020-10-04T00:00:00Z	PEP 640: Unused variable syntax ⌘ http://www.python.org/dev/peps/pep-0640
2020-10-24T00:00:00Z	PEP 643: Metadata for Package Source Distributions ⌘ https://www.python.org/dev/peps/pep-0643/
2020-10-27T00:00:00Z	PEP 644: Require OpenSSL 1.1 or newer ⌘ https://www.python.org/dev/peps/pep-0644/
2020-10-29T00:00:00Z	PEP 8102: 2021 Term steering council election ⌘ https://www.python.org/dev/peps/pep-8102/
2020-12-30T00:00:00Z	PEP 648: Extensible customizations of the interpreter at startup ⌘ [Read more...](https://www.python.org/dev/peps/pep-0648/)
2021-01-11T00:00:00Z	PEP 649: Deferred Evaluation Of Annotations Using Descriptors ⌘ [Read more...](https://www.python.org/dev/peps/pep-0649/)
2021-01-18T00:00:00Z	PEP 651: Robust Overflow Handling ⌘ [Read more...](https://www.python.org/dev/peps/pep-0651/)
2021-02-09T00:00:00Z	PEP 652: Maintaining the Stable ABI ⌘ [Read more...](https://www.python.org/dev/peps/pep-0652/)
2021-02-22T00:00:00Z	PEP 654: Exception Groups and except* ⌘ [Read more...](https://www.python.org/dev/peps/pep-0654/)
2021-03-17T00:00:00Z	PEP 656: Platform Tag for Linux Distributions Using Musl ⌘ [Read more...](https://www.python.org/dev/peps/pep-0656/)
2021-05-08T00:00:00Z	PEP 657: Include Fine Grained Error Locations in Tracebacks ⌘ [Read more...](https://www.python.org/dev/peps/pep-0657/)
2021-05-10T00:00:00Z	PEP 658: Static Distribution Metadata in the Simple Repository API ⌘ [Read more...](https://www.python.org/dev/peps/pep-0658/)
2021-06-06T00:00:00Z	PEP 661: Sentinel Values ⌘ [Read more...](https://www.python.org/dev/peps/pep-0661/)
2021-07-12T00:00:00Z	PEP 664: Python 3.11 Release Schedule ⌘ [Read more...](https://www.python.org/dev/peps/pep-0664/)
2021-07-29T00:00:00Z	PEP 665: Specifying Installation Requirements for Python Projects ⌘ [Read more...](https://www.python.org/dev/peps/pep-0665/)
2021-10-04T00:00:00Z	**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](https://www.python.org/dev/peps/pep-8103/)
2021-10-19T00:00:00Z	**PEP 670: Convert macros to functions in the Python C API**
Convert macros to static inline functions or regular functions. ⌘ [Read more](https://www.python.org/dev/peps/pep-0670/)
2021-10-24T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0671/)
2021-11-01T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0672/)
2021-11-10T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0673/)
2021-12-01T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0674/)
2021-12-13T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0677/)
2021-12-20T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0678/)
2022-01-07T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0679/)
2022-01-29T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0682/)
2022-02-10T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0683/)
2022-03-08T00:00:00Z	**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](https://www.python.org/dev/peps/pep-0685/)
2022-04-04T00:00:00Z	**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](https://peps.python.org/pep-0687/)
2022-03-18T00:00:00Z	**PEP 686: Make UTF-8 mode default**
This PEP proposes enabling UTF-8 mode by default. ⌘ [Read more](https://peps.python.org/pep-0686/)
2022-04-23T00:00:00Z	**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](https://peps.python.org/pep-0688/)
2022-04-29T00:00:00Z	**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](https://peps.python.org/pep-0690/)
2022-05-04T00:00:00Z	**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](https://peps.python.org/pep-0691/)
2022-05-24T00:00:00Z	**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](https://peps.python.org/pep-0693/)
2022-07-14T00:00:00Z	**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](https://peps.python.org/pep-0696/)
2022-08-23T00:00:00Z	**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](https://peps.python.org/pep-0697/)
2022-09-05T00:00:00Z	**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](https://peps.python.org/pep-0698/)
2022-10-03T00:00:00Z	**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](https://peps.python.org/pep-0699/)
2022-10-21T00:00:00Z	**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](https://peps.python.org/pep-0700/)
2022-11-08T00:00:00Z	**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](https://peps.python.org/pep-8104/)
2022-11-15T00:00:00Z	**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](https://peps.python.org/pep-0701/)
2022-12-30T00:00:00Z	**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](https://peps.python.org/pep-0702/)
2023-01-09T00:00:00Z	**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](https://peps.python.org/pep-0703/)
2023-01-16T00:00:00Z	**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](https://peps.python.org/pep-0704/)
2023-02-09T00:00:00Z	**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](https://peps.python.org/pep-0706/)
2023-02-20T00:00:00Z	**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](https://peps.python.org/pep-0708/)
2023-02-24T00:00:00Z	**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](https://peps.python.org/pep-0709/)
2023-03-27T00:00:00Z	**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](https://peps.python.org/pep-0710/)
2023-04-06T00:00:00Z	**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](https://peps.python.org/pep-0711/)
2023-04-20T00:00:00Z	**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](https://peps.python.org/pep-0713/)
2023-06-06T00:00:00Z	**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](https://peps.python.org/pep-0714/)
2023-07-12T00:00:00Z	**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](https://peps.python.org/pep-0721/)
2023-07-19T00:00:00Z	**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](https://peps.python.org/pep-0722/)
2023-07-19T00:00:00Z	**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](https://peps.python.org/pep-0722/)
2023-08-04T00:00:00Z	**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](https://peps.python.org/pep-0723/)
2023-08-17T00:00:00Z	**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](https://peps.python.org/pep-0725/)
2023-08-28T00:00:00Z	**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](https://peps.python.org/pep-0727/)
2023-09-19T00:00:00Z	**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](https://peps.python.org/pep-0729/)
2023-10-09T00:00:00Z	**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](https://peps.python.org/pep-0730/)
2023-10-14T00:00:00Z	**PEP 732: The Python Documentation Editorial Board**
This PEP: ⌘ [Read more](https://peps.python.org/pep-0732/)
2023-10-23T00:00:00Z	**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](https://peps.python.org/pep-8105/)
2023-11-06T00:00:00Z	**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](https://peps.python.org/pep-0734/)
2023-11-29T00:00:00Z	**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](https://peps.python.org/pep-0737/)
2023-12-12T00:00:00Z	**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](https://peps.python.org/pep-0738/)
2024-01-18T00:00:00Z	**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](https://peps.python.org/pep-0741/)
2024-01-18T00:00:00Z	**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](https://peps.python.org/pep-0741/)
2024-02-07T00:00:00Z	**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](https://peps.python.org/pep-0742/)
2024-03-11T00:00:00Z	**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](https://peps.python.org/pep-0743/)
2024-04-11T00:00:00Z	**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](https://peps.python.org/pep-0744/)
2024-04-24T00:00:00Z	**PEP 745: Python 3.14 Release Schedule**
This document describes the development and release schedule for Python 3.14. ⌘ [Read more](https://peps.python.org/pep-0745/)
2024-05-20T00:00:00Z	**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](https://peps.python.org/pep-0746/)
2024-06-11T00:00:00Z	**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](https://peps.python.org/pep-2026/)
2024-07-24T00:00:00Z	**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](https://peps.python.org/pep-0751/)
2024-08-13T00:00:00Z	**PEP 752: Package repository namespaces**
This PEP specifies a way for organizations to reserve package name prefixes for future uploads. ⌘ [Read more](https://peps.python.org/pep-0752/)
2024-09-05T00:00:00Z	**PEP 755: Implicit namespace policy for PyPI**
This PEP codifies an implementation of PEP 752 for PyPI 1. ⌘ [Read more](https://peps.python.org/pep-0755/)
2024-09-13T00:00:00Z	**PEP 756: Add PyUnicode_Export() and PyUnicode_Import() C functions**
Add functions to the limited C API version 3.14: ⌘ [Read more](https://peps.python.org/pep-0756/)
2024-09-30T00:00:00Z	**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](https://peps.python.org/pep-0758/)
2024-10-08T00:00:00Z	**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](https://peps.python.org/pep-0761/)
2024-10-11T00:00:00Z	**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](https://peps.python.org/pep-0762/)
2024-10-21T00:00:00Z	**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](https://peps.python.org/pep-8106/)
2024-10-24T00:00:00Z	**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](https://peps.python.org/pep-0763/)
2024-11-15T00:00:00Z	**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](https://peps.python.org/pep-0765/)
2024-11-18T00:00:00Z	**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](https://peps.python.org/pep-0766/)
2024-11-25T00:00:00Z	**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](https://peps.python.org/pep-0768/)