https://peps.python.org/peps.rss · source : Welcome to Python.org
Newest Python Enhancement Proposals (PEPs): Information on new language features and some meta-information like release procedure and schedules.
📈 4,8 articles / mois — soit ~1 article tous les 6,3 jours · dernier le 20/09/2026 00:00
10 articles datés · regroupés par mois.
✅ 6 bons points sur 6 critères évalués.
🔒 Le détail du calcul (note par critère : intégrité technique, découvrabilité, conformité podcast ouvert…) est réservé aux abonnés — connectez-vous.
Currently, the Python interpreter allows any expression to be used as an annotation. But their most popular usage, type annotations, are restricted to only a small subset of possible expressions. This is because type annotations need to be introspectable at runtime and many valid expressions produce…
Lire l'article →This PEP proposes adding two new operators.
Lire l'article →This PEP proposes adding two new operators.
Lire l'article →This PEP proposes adding a new cyclic garbage collector to CPython. The new collector will be both generational and incremental. Collections will alternate: a young collection, then an (incremental) old collection, then a young collection, and so on.
Lire l'article →This PEP proposes preserving a string literal immediately following a type statement as the resulting type alias object’s __doc__ attribute, exposing that documentation through ast, and displaying it through pydoc and help(). It follows the placement already supported by source-based documentation t…
Lire l'article →This PEP enables the use of non-attribute names as value patterns in match statements. A name prefixed with a dot is looked up using the normal name resolution rules and compared to the match subject by equality in the same manner as existing value patterns, instead of being treated as a capture pat…
Lire l'article →This PEP proposes standardizing the format of error responses returned by the simple repository API.
Lire l'article →This PEP proposes adding two new builtin functions, public() and private(), which document the public interface of a module by keeping its __all__ synchronized with the names actually defined to be public in that module. Both are used as decorators (@public and @private) on class and function defini…
Lire l'article →Large libraries separate their implementation layout (the tree of modules convenient for maintainers) from their public layout (the shallower, curated tree they present to users). Building that public layout today means choosing between two imperfect options.
Lire l'article →This PEP proposes an export statement that modules can use to express intent about the visibility of variables from outside the module.
Lire l'article →