Created
November 9, 2022 20:51
-
-
Save ptmcg/f9f53f02e91f2856c0d3675d4a886b76 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| [ | |
| {"id": "1", "title": "PEP Purpose and Guidelines", "authors": "Warsaw, Hylton, Goodger, Coghlan", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "13-Jun-2000", "python_version": null, "post_history": "21-Mar-2001, 29-Jul-2002, 03-May-2003, 05-May-2012, 07-Apr-2013", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0001/", "abstract": ""}, | |
| {"id": "2", "title": "Procedure for Adding New Modules", "authors": "Cannon, Faassen", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "07-Jul-2001", "python_version": null, "post_history": "07-Jul-2001, 09-Mar-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0002/", "abstract": "\nIntroduction\nThe Python Standard Library contributes significantly to Python's\nsuccess. The language comes with \"batteries included\", so it is easy\nfor people to become productive with just the standard library alone.\nIt is therefore important that the usefulness of the standard library\nbe maintained.\nDue to the visibility and importance of the standard library, it must\nbe maintained thoughtfully. As such, any code within it must be\nmaintained by Python's development team which leads to a perpetual\ncost to each addition made. There is also added cognitive load for\nusers in familiarizing themselves with what is in the standard\nlibrary to be considered.\nNew functionality is commonly added to the library in the form of new\nmodules. This PEP will describe the procedure for the addition of\nnew modules. PEP 4 deals with procedures for deprecation of modules;\nthe removal of old and unused modules from the standard library.\n"}, | |
| {"id": "3", "title": "Guidelines for Handling Bug Reports", "authors": "Hylton", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "25-Sep-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0003/", "abstract": "\nIntroduction\nThis PEP contained guidelines for handling bug reports in the Python\nbug tracker. It has been replaced by the Developer's Guide\ndescription of issue triaging at\nhttps://docs.python.org/devguide/triaging.html\n\n\nGuidelines for people submitting Python bugs are at\nhttp://docs.python.org/bugs.html\n\n\n"}, | |
| {"id": "4", "title": "Deprecation of Standard Modules", "authors": "Cannon, von L\u00f6wis", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "01-Oct-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0004/", "abstract": "\nIntroduction\nWhen new modules were added to the standard Python library in the\npast, it was not possible to foresee whether they would still be\nuseful in the future. Even though Python \"Comes With Batteries\nIncluded\", batteries may discharge over time. Carrying old modules\naround is a burden on the maintainer, especially when there is no\ninterest in the module anymore.\nAt the same time, removing a module from the distribution is\ndifficult, as it is not known in general whether anybody is still\nusing it. This PEP defines a procedure for removing modules from the\nstandard Python library. Usage of a module may be 'deprecated', which\nmeans that it may be removed from a future Python release.\n"}, | |
| {"id": "5", "title": "Guidelines for Language Evolution", "authors": "Prescod", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "26-Oct-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0005/", "abstract": "\nAbstract\nIn the natural evolution of programming languages it is sometimes\nnecessary to make changes that modify the behavior of older programs.\nThis PEP proposes a policy for implementing these changes in a manner\nrespectful of the installed base of Python users.\n"}, | |
| {"id": "6", "title": "Bug Fix Releases", "authors": "Aahz, Baxter", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "15-Mar-2001", "python_version": null, "post_history": "15-Mar-2001, 18-Apr-2001, 19-Aug-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0006/", "abstract": "\nAbstract\nPython has historically had only a single fork of development, with\nreleases having the combined purpose of adding new features and\ndelivering bug fixes (these kinds of releases will be referred to as\n\"major releases\"). This PEP describes how to fork off maintenance, or\nbug fix, releases of old versions for the primary purpose of fixing\nbugs.\nThis PEP is not, repeat NOT, a guarantee of the existence of bug fix\nreleases; it only specifies a procedure to be followed if bug fix\nreleases are desired by enough of the Python community willing to do\nthe work.\n"}, | |
| {"id": "7", "title": "Style Guide for C Code", "authors": "GvR, Warsaw", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "05-Jul-2001", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0007/", "abstract": "\nIntroduction\nThis document gives coding conventions for the C code comprising the C\nimplementation of Python. Please see the companion informational PEP\ndescribing style guidelines for Python code.\nNote, rules are there to be broken. Two good reasons to break a\nparticular rule:\n\nWhen applying the rule would make the code less readable, even for\nsomeone who is used to reading code that follows the rules.\nTo be consistent with surrounding code that also breaks it (maybe\nfor historic reasons) - although this is also an opportunity to\nclean up someone else's mess (in true XP style).\n\n"}, | |
| {"id": "8", "title": "Style Guide for Python Code", "authors": "GvR, Warsaw, Coghlan", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "05-Jul-2001", "python_version": null, "post_history": "05-Jul-2001, 01-Aug-2013", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0008/", "abstract": "\nIntroduction\nThis document gives coding conventions for the Python code comprising\nthe standard library in the main Python distribution. Please see the\ncompanion informational PEP describing style guidelines for the C code\nin the C implementation of Python.\nThis document and PEP 257 (Docstring Conventions) were adapted from\nGuido's original Python Style Guide essay, with some additions from\nBarry's style guide [2].\nThis style guide evolves over time as additional conventions are\nidentified and past conventions are rendered obsolete by changes in\nthe language itself.\nMany projects have their own coding style guidelines. In the event of any\nconflicts, such project-specific guides take precedence for that project.\n"}, | |
| {"id": "9", "title": "Sample Plaintext PEP Template", "authors": "Warsaw", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "14-Aug-2001", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/2YMHVPRDWGQLA5A2FKXE2JMLM2HQEEGW/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0009/", "abstract": ""}, | |
| {"id": "10", "title": "Voting Guidelines", "authors": "Warsaw", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "07-Mar-2002", "python_version": null, "post_history": "07-Mar-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0010/", "abstract": "\nAbstract\nThis PEP outlines the python-dev voting guidelines. These guidelines\nserve to provide feedback or gauge the \"wind direction\" on a\nparticular proposal, idea, or feature. They don't have a binding\nforce.\n"}, | |
| {"id": "11", "title": "CPython platform support", "authors": "von L\u00f6wis, Cannon", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "07-Jul-2002", "python_version": null, "post_history": "`18-Aug-2007 <https://mail.python.org/archives/list/python-dev@python.org/thread/DSSGXU5LBCMKYMZBRVB6RF3YAB6ST5AV/>`__, `14-May-2014 <https://mail.python.org/archives/list/python-dev@python.org/thread/T7WTUJ6TD3IGYGWV3M4PHJWNLM2WPZAW/>`__, `20-Feb-2015 <https://mail.python.org/archives/list/python-dev@python.org/thread/OEQHRR2COYZDL6LZ42RBZOMIUB32WI34/#L3K7IKGVT4ND45SKAJPJ3Q2ADVK5KP52>`__, `10-Mar-2022 <https://mail.python.org/archives/list/python-committers@python.org/thread/K757345KX6W5ZLTWYBUXOXQTJJTL7GW5/>`__,", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0011/", "abstract": "\nAbstract\nThis PEP documents how an operating system (platform) becomes\nsupported in CPython, what platforms are currently supported, and\ndocuments past support.\n"}, | |
| {"id": "12", "title": "Sample reStructuredText PEP Template", "authors": "Goodger, Warsaw, Cannon", "discussions_to": null, "status": "Active", "type": "Process", "topic": "", "created": "05-Aug-2002", "python_version": null, "post_history": "`30-Aug-2002 <https://mail.python.org/archives/list/python-dev@python.org/thread/KX3AS7QAY26QH3WIUAEOCCNXQ4V2TGGV/>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0012/", "abstract": "\nAbstract\nThis PEP provides a boilerplate or sample template for creating your\nown reStructuredText PEPs. In conjunction with the content guidelines\nin PEP 1, this should make it easy for you to conform your own\nPEPs to the format outlined below.\nNote: if you are reading this PEP via the web, you should first grab\nthe text (reStructuredText) source of this PEP in order to complete\nthe steps below. DO NOT USE THE HTML FILE AS YOUR TEMPLATE!\nThe source for this (or any) PEP can be found in the\nPEPs repository,\nas well as via a link at the bottom of each PEP.\n"}, | |
| {"id": "13", "title": "Python Language Governance", "authors": "python-dev", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "16-Dec-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0013/", "abstract": "\nAbstract\nThis PEP defines the formal governance process for Python, and records\nhow this has changed over time. Currently, governance is based around\na steering council. The council has broad authority, which they seek\nto exercise as rarely as possible.\n"}, | |
| {"id": "20", "title": "The Zen of Python", "authors": "Peters", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "19-Aug-2004", "python_version": null, "post_history": "22-Aug-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0020/", "abstract": "\nAbstract\nLong time Pythoneer Tim Peters succinctly channels the BDFL's guiding\nprinciples for Python's design into 20 aphorisms, only 19 of which\nhave been written down.\n"}, | |
| {"id": "42", "title": "Feature Requests", "authors": "Hylton", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "12-Sep-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0042/", "abstract": "\nIntroduction\nThis PEP contains a list of feature requests that may be considered\nfor future versions of Python. Large feature requests should not be\nincluded here, but should be described in separate PEPs; however a\nlarge feature request that doesn't have its own PEP can be listed here\nuntil its own PEP is created. See PEP 0 for details.\nThis PEP was created to allow us to close bug reports that are really\nfeature requests. Marked as Open, they distract from the list of real\nbugs (which should ideally be less than a page). Marked as Closed,\nthey tend to be forgotten. The procedure now is: if a bug report is\nreally a feature request, add the feature request to this PEP; mark\nthe bug as \"feature request\", \"later\", and \"closed\"; and add a comment\nto the bug saying that this is the case (mentioning the PEP\nexplicitly). It is also acceptable to move large feature requests\ndirectly from the bugs database to a separate PEP.\nThis PEP should really be separated into four different categories\n(categories due to Laura Creighton):\n\nBDFL rejects as a bad idea. Don't come back with it.\nBDFL will put in if somebody writes the code. (Or at any rate,\nBDFL will say 'change this and I will put it in' if you show up\nwith code.)possibly divided into:\n\n\nBDFL would really like to see some code!\nBDFL is never going to be enthusiastic about this, but\nwill work it in when it's easy.\n\n\n\nIf you show up with code, BDFL will make a pronouncement. It might\nbe ICK.\nThis is too vague. This is rejected, but only on the grounds of\nvagueness. If you like this enhancement, make a new PEP.\n\n"}, | |
| {"id": "100", "title": "Python Unicode Integration", "authors": "Lemburg", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "10-Mar-2000", "python_version": "2.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0100/", "abstract": "\nIntroduction\nThe idea of this proposal is to add native Unicode 3.0 support to\nPython in a way that makes use of Unicode strings as simple as\npossible without introducing too many pitfalls along the way.\nSince this goal is not easy to achieve - strings being one of the\nmost fundamental objects in Python - we expect this proposal to\nundergo some significant refinements.\nNote that the current version of this proposal is still a bit\nunsorted due to the many different aspects of the Unicode-Python\nintegration.\nThe latest version of this document is always available at:\nhttp://starship.python.net/~lemburg/unicode-proposal.txt\nOlder versions are available as:\nhttp://starship.python.net/~lemburg/unicode-proposal-X.X.txt\n[ed. note: new revisions should be made to this PEP document,\nwhile the historical record previous to version 1.7 should be\nretrieved from MAL's url, or Misc/unicode.txt]\n"}, | |
| {"id": "101", "title": "Doing Python Releases 101", "authors": "Warsaw, GvR", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "22-Aug-2001", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": "102", "superseded_by": null, "url": "https://peps.python.org/pep-0101/", "abstract": "\nAbstract\nMaking a Python release is a thrilling and crazy process. You've heard\nthe expression \"herding cats\"? Imagine trying to also saddle those\npurring little creatures up, and ride them into town, with some of their\nbuddies firmly attached to your bare back, anchored by newly sharpened\nclaws. At least they're cute, you remind yourself.\nActually, no that's a slight exaggeration <wink>. The Python release\nprocess has steadily improved over the years and now, with the help of our\namazing community, is really not too difficult. This PEP attempts to\ncollect, in one place, all the steps needed to make a Python release. It\nis organized as a recipe and you can actually print this out and check\nitems off as you complete them.\n"}, | |
| {"id": "102", "title": "Doing Python Micro Releases", "authors": "Baxter, Warsaw, GvR", "discussions_to": null, "status": "Superseded", "type": "Informational", "topic": "", "created": "09-Jan-2002", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": "101", "url": "https://peps.python.org/pep-0102/", "abstract": "\nAbstract\nMaking a Python release is an arduous process that takes a\nminimum of half a day's work even for an experienced releaser.\nUntil recently, most - if not all - of that burden was borne by\nGuido himself. But several recent releases have been performed by\nother folks, so this PEP attempts to collect, in one place, all\nthe steps needed to make a Python bugfix release.\nThe major Python release process is covered in PEP 101 - this PEP\nis just PEP 101, trimmed down to only include the bits that are\nrelevant for micro releases, a.k.a. patch, or bug fix releases.\nIt is organized as a recipe and you can actually print this out and\ncheck items off as you complete them.\n"}, | |
| {"id": "103", "title": "Collecting information about git", "authors": "Broytman", "discussions_to": null, "status": "Withdrawn", "type": "Informational", "topic": "", "created": "01-Jun-2015", "python_version": null, "post_history": "12-Sep-2015", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0103/", "abstract": "\nAbstract\nThis Informational PEP collects information about git. There is, of\ncourse, a lot of documentation for git, so the PEP concentrates on\nmore complex (and more related to Python development) issues,\nscenarios and examples.\nThe plan is to extend the PEP in the future collecting information\nabout equivalence of Mercurial and git scenarios to help migrating\nPython development from Mercurial to git.\nThe author of the PEP doesn't currently plan to write a Process PEP on\nmigration Python development from Mercurial to git.\n"}, | |
| {"id": "160", "title": "Python 1.6 Release Schedule", "authors": "Drake", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "25-Jul-2000", "python_version": "1.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0160/", "abstract": "\nIntroduction\nThis PEP describes the Python 1.6 release schedule. The CVS\nrevision history of this file contains the definitive historical\nrecord.\nThis release will be produced by BeOpen PythonLabs staff for the\nCorporation for National Research Initiatives (CNRI).\n"}, | |
| {"id": "200", "title": "Python 2.0 Release Schedule", "authors": "Hylton", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "12-Jul-2000", "python_version": "2.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0200/", "abstract": "\nIntroduction\nThis PEP describes the Python 2.0 release schedule, tracking the\nstatus and ownership of the major new features, summarizes discussions\nheld in mailing list forums, and provides URLs for further\ninformation, patches, and other outstanding issues. The CVS revision\nhistory of this file contains the definitive historical record.\n"}, | |
| {"id": "201", "title": "Lockstep Iteration", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "13-Jul-2000", "python_version": "2.0", "post_history": "27-Jul-2000", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0201/", "abstract": "\nIntroduction\nThis PEP describes the 'lockstep iteration' proposal. This PEP tracks\nthe status and ownership of this feature, slated for introduction in\nPython 2.0. It contains a description of the feature and outlines\nchanges necessary to support the feature. This PEP summarizes\ndiscussions held in mailing list forums, and provides URLs for further\ninformation, where appropriate. The CVS revision history of this file\ncontains the definitive historical record.\n"}, | |
| {"id": "202", "title": "List Comprehensions", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "13-Jul-2000", "python_version": "2.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0202/", "abstract": "\nIntroduction\nThis PEP describes a proposed syntactical extension to Python, list\ncomprehensions.\n"}, | |
| {"id": "203", "title": "Augmented Assignments", "authors": "Wouters", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "13-Jul-2000", "python_version": "2.0", "post_history": "14-Aug-2000", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0203/", "abstract": "\nIntroduction\nThis PEP describes the augmented assignment proposal for Python 2.0. This\nPEP tracks the status and ownership of this feature, slated for introduction\nin Python 2.0. It contains a description of the feature and outlines changes\nnecessary to support the feature. This PEP summarizes discussions held in\nmailing list forums [1], and provides URLs for further information where\nappropriate. The CVS revision history of this file contains the definitive\nhistorical record.\n"}, | |
| {"id": "204", "title": "Range Literals", "authors": "Wouters", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "14-Jul-2000", "python_version": "2.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0204/", "abstract": "\nIntroduction\nThis PEP describes the \"range literal\" proposal for Python 2.0.\nThis PEP tracks the status and ownership of this feature, slated\nfor introduction in Python 2.0. It contains a description of the\nfeature and outlines changes necessary to support the feature.\nThis PEP summarizes discussions held in mailing list forums, and\nprovides URLs for further information, where appropriate. The CVS\nrevision history of this file contains the definitive historical\nrecord.\n"}, | |
| {"id": "205", "title": "Weak References", "authors": "Drake", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "14-Jul-2000", "python_version": "2.1", "post_history": "11-Jan-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0205/", "abstract": ""}, | |
| {"id": "206", "title": "Python Advanced Library", "authors": "Kuchling", "discussions_to": null, "status": "Withdrawn", "type": "Informational", "topic": "", "created": "14-Jul-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0206/", "abstract": "\nIntroduction\nThis PEP describes the Python Advanced Library, a collection of\nhigh-quality and frequently-used third party extension modules.\n"}, | |
| {"id": "207", "title": "Rich Comparisons", "authors": "GvR, Ascher", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "25-Jul-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0207/", "abstract": "\nAbstract\nThis PEP proposes several new features for comparisons:\n\nAllow separately overloading of <, >, <=, >=, ==, !=, both in\nclasses and in C extensions.\nAllow any of those overloaded operators to return something else\nbesides a Boolean result.\n\n"}, | |
| {"id": "208", "title": "Reworking the Coercion Model", "authors": "Schemenauer, Lemburg", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "04-Dec-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0208/", "abstract": "\nAbstract\nMany Python types implement numeric operations. When the arguments of\na numeric operation are of different types, the interpreter tries to\ncoerce the arguments into a common type. The numeric operation is\nthen performed using this common type. This PEP proposes a new type\nflag to indicate that arguments to a type's numeric operations should\nnot be coerced. Operations that do not support the supplied types\nindicate it by returning a new singleton object. Types which do not\nset the type flag are handled in a backwards compatible manner.\nAllowing operations handle different types is often simpler, more\nflexible, and faster than having the interpreter do coercion.\n"}, | |
| {"id": "209", "title": "Multi-dimensional Arrays", "authors": "Barrett, Oliphant", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "03-Jan-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0209/", "abstract": "\nAbstract\nThis PEP proposes a redesign and re-implementation of the multi-\ndimensional array module, Numeric, to make it easier to add new\nfeatures and functionality to the module. Aspects of Numeric 2\nthat will receive special attention are efficient access to arrays\nexceeding a gigabyte in size and composed of inhomogeneous data\nstructures or records. The proposed design uses four Python\nclasses: ArrayType, UFunc, Array, and ArrayView; and a low-level\nC-extension module, _ufunc, to handle the array operations\nefficiently. In addition, each array type has its own C-extension\nmodule which defines the coercion rules, operations, and methods\nfor that type. This design enables new types, features, and\nfunctionality to be added in a modular fashion. The new version\nwill introduce some incompatibilities with the current Numeric.\n"}, | |
| {"id": "210", "title": "Decoupling the Interpreter Loop", "authors": "Ascher", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "15-Jul-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0210/", "abstract": ""}, | |
| {"id": "211", "title": "Adding A New Outer Product Operator", "authors": "Wilson", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "15-Jul-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0211/", "abstract": "\nIntroduction\nThis PEP describes a proposal to define @ (pronounced \"across\")\nas a new outer product operator in Python 2.2. When applied to\nsequences (or other iterable objects), this operator will combine\ntheir iterators, so that:\nfor (i, j) in S @ T:\n pass\n\n\nwill be equivalent to:\nfor i in S:\n for j in T:\n pass\n\n\nClasses will be able to overload this operator using the special\nmethods __across__, __racross__, and __iacross__. In\nparticular, the new Numeric module (PEP 209) will overload this\noperator for multi-dimensional arrays to implement matrix\nmultiplication.\n"}, | |
| {"id": "212", "title": "Loop Counter Iteration", "authors": "Schneider-Kamp", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "22-Aug-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0212/", "abstract": "\nIntroduction\nThis PEP describes the often proposed feature of exposing the loop\ncounter in for-loops. This PEP tracks the status and ownership of\nthis feature. It contains a description of the feature and\noutlines changes necessary to support the feature. This PEP\nsummarizes discussions held in mailing list forums, and provides\nURLs for further information, where appropriate. The CVS revision\nhistory of this file contains the definitive historical record.\n"}, | |
| {"id": "213", "title": "Attribute Access Handlers", "authors": "Prescod", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "21-Jul-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0213/", "abstract": "\nIntroduction\nIt is possible (and even relatively common) in Python code and\nin extension modules to \"trap\" when an instance's client code\nattempts to set an attribute and execute code instead. In other\nwords, it is possible to allow users to use attribute assignment/\nretrieval/deletion syntax even though the underlying implementation\nis doing some computation rather than directly modifying a\nbinding.\nThis PEP describes a feature that makes it easier, more efficient\nand safer to implement these handlers for Python instances.\n"}, | |
| {"id": "214", "title": "Extended Print Statement", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "24-Jul-2000", "python_version": "2.0", "post_history": "16-Aug-2000", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0214/", "abstract": "\nIntroduction\nThis PEP describes a syntax to extend the standard 'print'\nstatement so that it can be used to print to any file-like object,\ninstead of the default sys.stdout. This PEP tracks the status and\nownership of this feature. It contains a description of the\nfeature and outlines changes necessary to support the feature.\nThis PEP summarizes discussions held in mailing list forums, and\nprovides URLs for further information, where appropriate. The CVS\nrevision history of this file contains the definitive historical\nrecord.\n"}, | |
| {"id": "215", "title": "String Interpolation", "authors": "Yee", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "", "created": "24-Jul-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": "292", "url": "https://peps.python.org/pep-0215/", "abstract": "\nAbstract\nThis document proposes a string interpolation feature for Python\nto allow easier string formatting. The suggested syntax change\nis the introduction of a '$' prefix that triggers the special\ninterpretation of the '$' character within a string, in a manner\nreminiscent to the variable interpolation found in Unix shells,\nawk, Perl, or Tcl.\n"}, | |
| {"id": "216", "title": "Docstring Format", "authors": "Zadka", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "31-Jul-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": "287", "url": "https://peps.python.org/pep-0216/", "abstract": "\nAbstract\nNamed Python objects, such as modules, classes and functions, have a\nstring attribute called __doc__. If the first expression inside\nthe definition is a literal string, that string is assigned\nto the __doc__ attribute.\nThe __doc__ attribute is called a documentation string, or docstring.\nIt is often used to summarize the interface of the module, class or\nfunction. However, since there is no common format for documentation\nstring, tools for extracting docstrings and transforming those into\ndocumentation in a standard format (e.g., DocBook) have not sprang\nup in abundance, and those that do exist are for the most part\nunmaintained and unused.\n"}, | |
| {"id": "217", "title": "Display Hook for Interactive Use", "authors": "Zadka", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "31-Jul-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0217/", "abstract": "\nAbstract\nPython's interactive mode is one of the implementation's great\nstrengths - being able to write expressions on the command line\nand get back a meaningful output. However, the output function\ncannot be all things to all people, and the current output\nfunction too often falls short of this goal. This PEP describes a\nway to provides alternatives to the built-in display function in\nPython, so users will have control over the output from the\ninteractive interpreter.\n"}, | |
| {"id": "218", "title": "Adding a Built-In Set Object Type", "authors": "Wilson, Hettinger", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "31-Jul-2000", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0218/", "abstract": "\nIntroduction\nThis PEP proposes adding a Set module to the standard Python\nlibrary, and to then make sets a built-in Python type if that\nmodule is widely used. After explaining why sets are desirable,\nand why the common idiom of using dictionaries in their place is\ninadequate, we describe how we intend built-in sets to work, and\nthen how the preliminary Set module will behave. The last\nsection discusses the mutability (or otherwise) of sets and set\nelements, and the solution which the Set module will implement.\n"}, | |
| {"id": "219", "title": "Stackless Python", "authors": "McMillan", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "14-Aug-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0219/", "abstract": "\nIntroduction\nThis PEP discusses changes required to core Python in order to\nefficiently support generators, microthreads and coroutines. It is\nrelated to PEP 220, which describes how Python should be extended\nto support these facilities. The focus of this PEP is strictly on\nthe changes required to allow these extensions to work.\nWhile these PEPs are based on Christian Tismer's Stackless [1]\nimplementation, they do not regard Stackless as a reference\nimplementation. Stackless (with an extension module) implements\ncontinuations, and from continuations one can implement\ncoroutines, microthreads (as has been done by Will Ware [2]) and\ngenerators. But in more than a year, no one has found any other\nproductive use of continuations, so there seems to be no demand\nfor their support.\nHowever, Stackless support for continuations is a relatively minor\npiece of the implementation, so one might regard it as \"a\"\nreference implementation (rather than \"the\" reference\nimplementation).\n"}, | |
| {"id": "220", "title": "Coroutines, Generators, Continuations", "authors": "McMillan", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "14-Aug-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0220/", "abstract": "\nAbstract\nDemonstrates why the changes described in the stackless PEP are\ndesirable. A low-level continuations module exists. With it,\ncoroutines and generators and \"green\" threads can be written. A\nhigher level module that makes coroutines and generators easy to\ncreate is desirable (and being worked on). The focus of this PEP\nis on showing how coroutines, generators, and green threads can\nsimplify common programming problems.\n"}, | |
| {"id": "221", "title": "Import As", "authors": "Wouters", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Aug-2000", "python_version": "2.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0221/", "abstract": "\nIntroduction\nThis PEP describes the import as proposal for Python 2.0. This\nPEP tracks the status and ownership of this feature. It contains\na description of the feature and outlines changes necessary to\nsupport the feature. The CVS revision history of this file\ncontains the definitive historical record.\n"}, | |
| {"id": "222", "title": "Web Library Enhancements", "authors": "Kuchling", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "18-Aug-2000", "python_version": "2.1", "post_history": "22-Dec-2000", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0222/", "abstract": "\nAbstract\nThis PEP proposes a set of enhancements to the CGI development\nfacilities in the Python standard library. Enhancements might be\nnew features, new modules for tasks such as cookie support, or\nremoval of obsolete code.\nThe original intent was to make improvements to Python 2.1.\nHowever, there seemed little interest from the Python community,\nand time was lacking, so this PEP has been deferred to some future\nPython release.\n"}, | |
| {"id": "223", "title": "Change the Meaning of ``\\x`` Escapes", "authors": "Peters", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "20-Aug-2000", "python_version": "2.0", "post_history": "23-Aug-2000", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0223/", "abstract": "\nAbstract\nChange \\x escapes, in both 8-bit and Unicode strings, to consume\nexactly the two hex digits following. The proposal views this as\ncorrecting an original design flaw, leading to clearer expression\nin all flavors of string, a cleaner Unicode story, better\ncompatibility with Perl regular expressions, and with minimal risk\nto existing code.\n"}, | |
| {"id": "224", "title": "Attribute Docstrings", "authors": "Lemburg", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "23-Aug-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0224/", "abstract": "\nIntroduction\nThis PEP describes the \"attribute docstring\" proposal for Python\n2.0. This PEP tracks the status and ownership of this feature.\nIt contains a description of the feature and outlines changes\nnecessary to support the feature. The CVS revision history of\nthis file contains the definitive historical record.\n"}, | |
| {"id": "225", "title": "Elementwise/Objectwise Operators", "authors": "Zhu, Lielens", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "19-Sep-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0225/", "abstract": "\nIntroduction\nThis PEP describes a proposal to add new operators to Python which are useful\nfor distinguishing elementwise and objectwise operations, and summarizes\ndiscussions in the news group comp.lang.python on this topic. See Credits and\nArchives section at end. Issues discussed here include:\n\nBackground.\nDescription of proposed operators and implementation issues.\nAnalysis of alternatives to new operators.\nAnalysis of alternative forms.\nCompatibility issues\nDescription of wider extensions and other related ideas.\n\nA substantial portion of this PEP describes ideas that do not go into the\nproposed extension. They are presented because the extension is essentially\nsyntactic sugar, so its adoption must be weighed against various possible\nalternatives. While many alternatives may be better in some aspects, the\ncurrent proposal appears to be overall advantageous.\nThe issues concerning elementwise-objectwise operations extends to wider areas\nthan numerical computation. This document also describes how the current\nproposal may be integrated with more general future extensions.\n"}, | |
| {"id": "226", "title": "Python 2.1 Release Schedule", "authors": "Hylton", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "16-Oct-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0226/", "abstract": "\nAbstract\nThis document describes the post Python 2.0 development and\nrelease schedule. According to this schedule, Python 2.1 will be\nreleased in April of 2001. The schedule primarily concerns\nitself with PEP-size items. Small bug fixes and changes will\noccur up until the first beta release.\n"}, | |
| {"id": "227", "title": "Statically Nested Scopes", "authors": "Hylton", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-Nov-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0227/", "abstract": "\nIntroduction\nThis proposal changes the rules for resolving free variables in\nPython functions. The new name resolution semantics will take\neffect with Python 2.2. These semantics will also be available in\nPython 2.1 by adding \"from __future__ import nested_scopes\" to the\ntop of a module. (See PEP 236.)\nThe Python 2.0 definition specifies exactly three namespaces to\ncheck for each name - the local namespace, the global namespace,\nand the builtin namespace. According to this definition, if a\nfunction A is defined within a function B, the names bound in B\nare not visible in A. The proposal changes the rules so that\nnames bound in B are visible in A (unless A contains a name\nbinding that hides the binding in B).\nThis specification introduces rules for lexical scoping that are\ncommon in Algol-like languages. The combination of lexical\nscoping and existing support for first-class functions is\nreminiscent of Scheme.\nThe changed scoping rules address two problems - the limited\nutility of lambda expressions (and nested functions in general),\nand the frequent confusion of new users familiar with other\nlanguages that support nested lexical scopes, e.g. the inability\nto define recursive functions except at the module level.\nThe lambda expression yields an unnamed function that evaluates a\nsingle expression. It is often used for callback functions. In\nthe example below (written using the Python 2.0 rules), any name\nused in the body of the lambda must be explicitly passed as a\ndefault argument to the lambda.\nfrom Tkinter import *\nroot = Tk()\nButton(root, text=\"Click here\",\n command=lambda root=root: root.test.configure(text=\"...\"))\n\n\nThis approach is cumbersome, particularly when there are several\nnames used in the body of the lambda. The long list of default\narguments obscures the purpose of the code. The proposed\nsolution, in crude terms, implements the default argument approach\nautomatically. The \"root=root\" argument can be omitted.\nThe new name resolution semantics will cause some programs to\nbehave differently than they did under Python 2.0. In some cases,\nprograms will fail to compile. In other cases, names that were\npreviously resolved using the global namespace will be resolved\nusing the local namespace of an enclosing function. In Python\n2.1, warnings will be issued for all statements that will behave\ndifferently.\n"}, | |
| {"id": "228", "title": "Reworking Python's Numeric Model", "authors": "Zadka, GvR", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "04-Nov-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0228/", "abstract": "\nAbstract\nToday, Python's numerical model is similar to the C numeric model:\nthere are several unrelated numerical types, and when operations\nbetween numerical types are requested, coercions happen. While\nthe C rationale for the numerical model is that it is very similar\nto what happens at the hardware level, that rationale does not\napply to Python. So, while it is acceptable to C programmers that\n2/3 == 0, it is surprising to many Python programmers.\nNOTE: in the light of recent discussions in the newsgroup, the\nmotivation in this PEP (and details) need to be extended.\n"}, | |
| {"id": "229", "title": "Using Distutils to Build Python", "authors": "Kuchling", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-Nov-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0229/", "abstract": "\nIntroduction\nThe Modules/Setup mechanism has some flaws:\n\nPeople have to remember to uncomment bits of Modules/Setup in\norder to get all the possible modules.\nMoving Setup to a new version of Python is tedious; new modules\nhave been added, so you can't just copy the older version, but\nhave to reconcile the two versions.\nUsers have to figure out where the needed libraries, such as\nzlib, are installed.\n\n"}, | |
| {"id": "230", "title": "Warning Framework", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Nov-2000", "python_version": "2.1", "post_history": "05-Nov-2000", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0230/", "abstract": "\nAbstract\nThis PEP proposes a C and Python level API, as well as command\nline flags, to issue warning messages and control what happens to\nthem. This is mostly based on GvR's proposal posted to python-dev\non 05-Nov-2000, with some ideas (such as using classes to\ncategorize warnings) merged in from Paul Prescod's\ncounter-proposal posted on the same date. Also, an attempt to\nimplement the proposal caused several small tweaks.\n"}, | |
| {"id": "231", "title": "__findattr__()", "authors": "Warsaw", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "30-Nov-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0231/", "abstract": "\nIntroduction\nThis PEP describes an extension to instance attribute lookup and\nmodification machinery, which allows pure-Python implementations\nof many interesting programming models. This PEP tracks the\nstatus and ownership of this feature. It contains a description\nof the feature and outlines changes necessary to support the\nfeature. This PEP summarizes discussions held in mailing list\nforums, and provides URLs for further information, where\nappropriate. The CVS revision history of this file contains the\ndefinitive historical record.\n"}, | |
| {"id": "232", "title": "Function Attributes", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "02-Dec-2000", "python_version": "2.1", "post_history": "20-Feb-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0232/", "abstract": "\nIntroduction\nThis PEP describes an extension to Python, adding attribute\ndictionaries to functions and methods. This PEP tracks the status\nand ownership of this feature. It contains a description of the\nfeature and outlines changes necessary to support the feature.\nThis PEP summarizes discussions held in mailing list forums, and\nprovides URLs for further information, where appropriate. The CVS\nrevision history of this file contains the definitive historical\nrecord.\n"}, | |
| {"id": "233", "title": "Python Online Help", "authors": "Prescod", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "11-Dec-2000", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0233/", "abstract": "\nAbstract\nThis PEP describes a command-line driven online help facility for\nPython. The facility should be able to build on existing\ndocumentation facilities such as the Python documentation and\ndocstrings. It should also be extensible for new types and\nmodules.\n"}, | |
| {"id": "234", "title": "Iterators", "authors": "Yee, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Jan-2001", "python_version": "2.1", "post_history": "30-Apr-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0234/", "abstract": "\nAbstract\nThis document proposes an iteration interface that objects can provide to\ncontrol the behaviour of for loops. Looping is customized by providing a\nmethod that produces an iterator object. The iterator provides a get next\nvalue operation that produces the next item in the sequence each time it is\ncalled, raising an exception when no more items are available.\nIn addition, specific iterators over the keys of a dictionary and over the\nlines of a file are proposed, and a proposal is made to allow spelling\ndict.has_key(key) as key in dict.\nNote: this is an almost complete rewrite of this PEP by the second author,\ndescribing the actual implementation checked into the trunk of the Python 2.2\nCVS tree. It is still open for discussion. Some of the more esoteric\nproposals in the original version of this PEP have been withdrawn for now;\nthese may be the subject of a separate PEP in the future.\n"}, | |
| {"id": "235", "title": "Import on Case-Insensitive Platforms", "authors": "Peters", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "21-Feb-2001", "python_version": "2.1", "post_history": "16-Feb-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0235/", "abstract": ""}, | |
| {"id": "236", "title": "Back to the __future__", "authors": "Peters", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Feb-2001", "python_version": "2.1", "post_history": "26-Feb-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0236/", "abstract": ""}, | |
| {"id": "237", "title": "Unifying Long Integers and Integers", "authors": "Zadka, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "11-Mar-2001", "python_version": "2.2", "post_history": "16-Mar-2001, 14-Aug-2001, 23-Aug-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0237/", "abstract": "\nAbstract\nPython currently distinguishes between two kinds of integers (ints): regular\nor short ints, limited by the size of a C long (typically 32 or 64 bits), and\nlong ints, which are limited only by available memory. When operations on\nshort ints yield results that don't fit in a C long, they raise an error.\nThere are some other distinctions too. This PEP proposes to do away with most\nof the differences in semantics, unifying the two types from the perspective\nof the Python user.\n"}, | |
| {"id": "238", "title": "Changing the Division Operator", "authors": "Zadka, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "11-Mar-2001", "python_version": "2.2", "post_history": "16-Mar-2001, 26-Jul-2001, 27-Jul-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0238/", "abstract": "\nAbstract\nThe current division (/) operator has an ambiguous meaning for numerical\narguments: it returns the floor of the mathematical result of division if the\narguments are ints or longs, but it returns a reasonable approximation of the\ndivision result if the arguments are floats or complex. This makes\nexpressions expecting float or complex results error-prone when integers are\nnot expected but possible as inputs.\nWe propose to fix this by introducing different operators for different\noperations: x/y to return a reasonable approximation of the mathematical\nresult of the division (\"true division\"), x//y to return the floor\n(\"floor division\"). We call the current, mixed meaning of x/y\n\"classic division\".\nBecause of severe backwards compatibility issues, not to mention a major\nflamewar on c.l.py, we propose the following transitional measures (starting\nwith Python 2.2):\n\nClassic division will remain the default in the Python 2.x series; true\ndivision will be standard in Python 3.0.\nThe // operator will be available to request floor division\nunambiguously.\nThe future division statement, spelled from __future__ import division,\nwill change the / operator to mean true division throughout the module.\nA command line option will enable run-time warnings for classic division\napplied to int or long arguments; another command line option will make true\ndivision the default.\nThe standard library will use the future division statement and the //\noperator when appropriate, so as to completely avoid classic division.\n\n"}, | |
| {"id": "239", "title": "Adding a Rational Type to Python", "authors": "Craig, Zadka", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "11-Mar-2001", "python_version": "2.2", "post_history": "16-Mar-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0239/", "abstract": "\nAbstract\nPython has no numeric type with the semantics of an unboundedly\nprecise rational number. This proposal explains the semantics of\nsuch a type, and suggests builtin functions and literals to\nsupport such a type. This PEP suggests no literals for rational\nnumbers; that is left for another PEP.\n"}, | |
| {"id": "240", "title": "Adding a Rational Literal to Python", "authors": "Craig, Zadka", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "11-Mar-2001", "python_version": "2.2", "post_history": "16-Mar-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0240/", "abstract": "\nAbstract\nA different PEP suggests adding a builtin rational type to\nPython. This PEP suggests changing the ddd.ddd float literal to a\nrational in Python, and modifying non-integer division to return\nit.\n"}, | |
| {"id": "241", "title": "Metadata for Python Software Packages", "authors": "Kuchling", "discussions_to": "distutils-sig@python.org", "status": "Superseded", "type": "Standards Track", "topic": "packaging", "created": "12-Mar-2001", "python_version": null, "post_history": "`19-Mar-2001 <https://mail.python.org/archives/list/distutils-sig@python.org/thread/46XPDHQHI3XAAJHEZAMAMKZYAI6K7NB6/>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": "314", "url": "https://peps.python.org/pep-0241/", "abstract": "\nIntroduction\nThis PEP describes a mechanism for adding metadata to Python\npackages. It includes specifics of the field names, and their\nsemantics and usage.\n"}, | |
| {"id": "242", "title": "Numeric Kinds", "authors": "Dubois", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "17-Mar-2001", "python_version": "2.2", "post_history": "17-Apr-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0242/", "abstract": "\nAbstract\nThis proposal gives the user optional control over the precision\nand range of numeric computations so that a computation can be\nwritten once and run anywhere with at least the desired precision\nand range. It is backward compatible with existing code. The\nmeaning of decimal literals is clarified.\n"}, | |
| {"id": "243", "title": "Module Repository Upload Mechanism", "authors": "Reifschneider", "discussions_to": "distutils-sig@python.org", "status": "Withdrawn", "type": "Standards Track", "topic": "packaging", "created": "18-Mar-2001", "python_version": "2.1", "post_history": "20-Mar-2001, 24-Mar-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0243/", "abstract": "\nAbstract\nFor a module repository system (such as Perl's CPAN) to be\nsuccessful, it must be as easy as possible for module authors to\nsubmit their work. An obvious place for this submit to happen is\nin the Distutils tools after the distribution archive has been\nsuccessfully created. For example, after a module author has\ntested their software (verifying the results of setup.py sdist),\nthey might type setup.py sdist --submit. This would flag\nDistutils to submit the source distribution to the archive server\nfor inclusion and distribution to the mirrors.\nThis PEP only deals with the mechanism for submitting the software\ndistributions to the archive, and does not deal with the actual\narchive/catalog server.\n"}, | |
| {"id": "244", "title": "The ``directive`` statement", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "20-Mar-2001", "python_version": "2.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0244/", "abstract": ""}, | |
| {"id": "245", "title": "Python Interface Syntax", "authors": "Pelletier", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "11-Jan-2001", "python_version": "2.2", "post_history": "21-Mar-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0245/", "abstract": "\nIntroduction\nThis PEP describes a proposed syntax for creating interface\nobjects in Python.\n"}, | |
| {"id": "246", "title": "Object Adaptation", "authors": "Martelli, Evans", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "21-Mar-2001", "python_version": "2.5", "post_history": "29-Mar-2001, 10-Jan-2005", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0246/", "abstract": "\nAbstract\nThis proposal puts forth an extensible cooperative mechanism for\nthe adaptation of an incoming object to a context which expects an\nobject supporting a specific protocol (say a specific type, class,\nor interface).\nThis proposal provides a built-in \"adapt\" function that, for any\nobject X and any protocol Y, can be used to ask the Python\nenvironment for a version of X compliant with Y. Behind the\nscenes, the mechanism asks object X: \"Are you now, or do you know\nhow to wrap yourself to provide, a supporter of protocol Y?\".\nAnd, if this request fails, the function then asks protocol Y:\n\"Does object X support you, or do you know how to wrap it to\nobtain such a supporter?\" This duality is important, because\nprotocols can be developed after objects are, or vice-versa, and\nthis PEP lets either case be supported non-invasively with regard\nto the pre-existing component[s].\nLastly, if neither the object nor the protocol know about each\nother, the mechanism may check a registry of adapter factories,\nwhere callables able to adapt certain objects to certain protocols\ncan be registered dynamically. This part of the proposal is\noptional: the same effect could be obtained by ensuring that\ncertain kinds of protocols and/or objects can accept dynamic\nregistration of adapter factories, for example via suitable custom\nmetaclasses. However, this optional part allows adaptation to be\nmade more flexible and powerful in a way that is not invasive to\neither protocols or other objects, thereby gaining for adaptation\nmuch the same kind of advantage that Python standard library's\n\"copy_reg\" module offers for serialization and persistence.\nThis proposal does not specifically constrain what a protocol\nis, what \"compliance to a protocol\" exactly means, nor what\nprecisely a wrapper is supposed to do. These omissions are\nintended to leave this proposal compatible with both existing\ncategories of protocols, such as the existing system of type and\nclasses, as well as the many concepts for \"interfaces\" as such\nwhich have been proposed or implemented for Python, such as the\none in PEP 245, the one in Zope3 [2], or the ones discussed in\nthe BDFL's Artima blog in late 2004 and early 2005 [3]. However,\nsome reflections on these subjects, intended to be suggestive and\nnot normative, are also included.\n"}, | |
| {"id": "247", "title": "API for Cryptographic Hash Functions", "authors": "Kuchling", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "23-Mar-2001", "python_version": null, "post_history": "20-Sep-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0247/", "abstract": "\nAbstract\nThere are several different modules available that implement cryptographic\nhashing algorithms such as MD5 or SHA. This document specifies a standard API\nfor such algorithms, to make it easier to switch between different\nimplementations.\n"}, | |
| {"id": "248", "title": "Python Database API Specification v1.0", "authors": "Lemburg", "discussions_to": "db-sig@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "29-Mar-2001", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": "249", "url": "https://peps.python.org/pep-0248/", "abstract": "\nIntroduction\nThis API has been defined to encourage similarity between the\nPython modules that are used to access databases. By doing this,\nwe hope to achieve a consistency leading to more easily understood\nmodules, code that is generally more portable across databases,\nand a broader reach of database connectivity from Python.\nThis interface specification consists of several items:\n\nModule Interface\nConnection Objects\nCursor Objects\nDBI Helper Objects\n\nComments and questions about this specification may be directed to\nthe SIG on Tabular Databases in Python\n(http://www.python.org/sigs/db-sig).\nThis specification document was last updated on: April 9, 1996.\nIt will be known as Version 1.0 of this specification.\n"}, | |
| {"id": "249", "title": "Python Database API Specification v2.0", "authors": "Lemburg", "discussions_to": "db-sig@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "29-Mar-2001", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": "248", "superseded_by": null, "url": "https://peps.python.org/pep-0249/", "abstract": "\nIntroduction\nThis API has been defined to encourage similarity between the Python\nmodules that are used to access databases. By doing this, we hope to\nachieve a consistency leading to more easily understood modules, code\nthat is generally more portable across databases, and a broader reach\nof database connectivity from Python.\nComments and questions about this specification may be directed to the\nSIG for Database Interfacing with Python.\nFor more information on database interfacing with Python and available\npackages see the Database Topic Guide.\nThis document describes the Python Database API Specification 2.0 and\na set of common optional extensions. The previous version 1.0 version\nis still available as reference, in PEP 248. Package writers are\nencouraged to use this version of the specification as basis for new\ninterfaces.\n"}, | |
| {"id": "250", "title": "Using site-packages on Windows", "authors": "Moore", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Mar-2001", "python_version": "2.2", "post_history": "30-Mar-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0250/", "abstract": "\nAbstract\nThe standard Python distribution includes a directory\nLib/site-packages, which is used on Unix platforms to hold\nlocally installed modules and packages. The site.py module\ndistributed with Python includes support for locating other\nmodules in the site-packages directory.\nThis PEP proposes that the site-packages directory should be used\non the Windows platform in a similar manner.\n"}, | |
| {"id": "251", "title": "Python 2.2 Release Schedule", "authors": "Warsaw, GvR", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "17-Apr-2001", "python_version": "2.2", "post_history": "14-Aug-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0251/", "abstract": "\nAbstract\nThis document describes the Python 2.2 development and release\nschedule. The schedule primarily concerns itself with PEP-sized\nitems. Small bug fixes and changes will occur up until the first\nbeta release.\nThe schedule below represents the actual release dates of Python\n2.2. Note that any subsequent maintenance releases of Python 2.2\nshould be covered by separate PEPs.\n"}, | |
| {"id": "252", "title": "Making Types Look More Like Classes", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Apr-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0252/", "abstract": "\nIntroduction\nOne of Python's oldest language warts is the difference between\nclasses and types. For example, you can't directly subclass the\ndictionary type, and the introspection interface for finding out\nwhat methods and instance variables an object has is different for\ntypes and for classes.\nHealing the class/type split is a big effort, because it affects\nmany aspects of how Python is implemented. This PEP concerns\nitself with making the introspection API for types look the same\nas that for classes. Other PEPs will propose making classes look\nmore like types, and subclassing from built-in types; these topics\nare not on the table for this PEP.\n"}, | |
| {"id": "253", "title": "Subtyping Built-in Types", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "14-May-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0253/", "abstract": "\nIntroduction\nTraditionally, types in Python have been created statically, by\ndeclaring a global variable of type PyTypeObject and initializing\nit with a static initializer. The slots in the type object\ndescribe all aspects of a Python type that are relevant to the\nPython interpreter. A few slots contain dimensional information\n(like the basic allocation size of instances), others contain\nvarious flags, but most slots are pointers to functions to\nimplement various kinds of behaviors. A NULL pointer means that\nthe type does not implement the specific behavior; in that case\nthe system may provide a default behavior or raise an exception\nwhen the behavior is invoked for an instance of the type. Some\ncollections of function pointers that are usually defined together\nare obtained indirectly via a pointer to an additional structure\ncontaining more function pointers.\nWhile the details of initializing a PyTypeObject structure haven't\nbeen documented as such, they are easily gleaned from the examples\nin the source code, and I am assuming that the reader is\nsufficiently familiar with the traditional way of creating new\nPython types in C.\nThis PEP will introduce the following features:\n\na type can be a factory function for its instances\ntypes can be subtyped in C\ntypes can be subtyped in Python with the class statement\nmultiple inheritance from types is supported (insofar as\npractical - you still can't multiply inherit from list and\ndictionary)\nthe standard coercion functions (int, tuple, str etc.) will\nbe redefined to be the corresponding type objects, which serve\nas their own factory functions\na class statement can contain a __metaclass__ declaration,\nspecifying the metaclass to be used to create the new class\na class statement can contain a __slots__ declaration,\nspecifying the specific names of the instance variables\nsupported\n\nThis PEP builds on PEP 252, which adds standard introspection to\ntypes; for example, when a particular type object initializes the\ntp_hash slot, that type object has a __hash__ method when\nintrospected. PEP 252 also adds a dictionary to type objects\nwhich contains all methods. At the Python level, this dictionary\nis read-only for built-in types; at the C level, it is accessible\ndirectly (but it should not be modified except as part of\ninitialization).\nFor binary compatibility, a flag bit in the tp_flags slot\nindicates the existence of the various new slots in the type\nobject introduced below. Types that don't have the\nPy_TPFLAGS_HAVE_CLASS bit set in their tp_flags slot are assumed\nto have NULL values for all the subtyping slots. (Warning: the\ncurrent implementation prototype is not yet consistent in its\nchecking of this flag bit. This should be fixed before the final\nrelease.)\nIn current Python, a distinction is made between types and\nclasses. This PEP together with PEP 254 will remove that\ndistinction. However, for backwards compatibility the distinction\nwill probably remain for years to come, and without PEP 254, the\ndistinction is still large: types ultimately have a built-in type\nas a base class, while classes ultimately derive from a\nuser-defined class. Therefore, in the rest of this PEP, I will\nuse the word type whenever I can - including base type or\nsupertype, derived type or subtype, and metatype. However,\nsometimes the terminology necessarily blends, for example an\nobject's type is given by its __class__ attribute, and subtyping\nin Python is spelled with a class statement. If further\ndistinction is necessary, user-defined classes can be referred to\nas \"classic\" classes.\n"}, | |
| {"id": "254", "title": "Making Classes Look More Like Types", "authors": "GvR", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "18-Jun-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0254/", "abstract": "\nAbstract\nThis PEP has not been written yet. Watch this space!\n"}, | |
| {"id": "255", "title": "Simple Generators", "authors": "Schemenauer, Peters, Hetland", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "18-May-2001", "python_version": "2.2", "post_history": "14-Jun-2001, 23-Jun-2001", "resolution": null, "requires": "234", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0255/", "abstract": "\nAbstract\nThis PEP introduces the concept of generators to Python, as well as a new\nstatement used in conjunction with them, the yield statement.\n"}, | |
| {"id": "256", "title": "Docstring Processing System Framework", "authors": "Goodger", "discussions_to": "doc-sig@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "01-Jun-2001", "python_version": null, "post_history": "13-Jun-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0256/", "abstract": "\nAbstract\nPython lends itself to inline documentation. With its built-in\ndocstring syntax, a limited form of Literate Programming is easy to\ndo in Python. However, there are no satisfactory standard tools for\nextracting and processing Python docstrings. The lack of a standard\ntoolset is a significant gap in Python's infrastructure; this PEP aims\nto fill the gap.\nThe issues surrounding docstring processing have been contentious and\ndifficult to resolve. This PEP proposes a generic Docstring\nProcessing System (DPS) framework, which separates out the components\n(program and conceptual), enabling the resolution of individual issues\neither through consensus (one solution) or through divergence (many).\nIt promotes standard interfaces which will allow a variety of plug-in\ncomponents (input context readers, markup parsers, and output format\nwriters) to be used.\nThe concepts of a DPS framework are presented independently of\nimplementation details.\n"}, | |
| {"id": "257", "title": "Docstring Conventions", "authors": "Goodger, GvR", "discussions_to": "doc-sig@python.org", "status": "Active", "type": "Informational", "topic": "", "created": "29-May-2001", "python_version": null, "post_history": "13-Jun-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0257/", "abstract": "\nAbstract\nThis PEP documents the semantics and conventions associated with\nPython docstrings.\n"}, | |
| {"id": "258", "title": "Docutils Design Specification", "authors": "Goodger", "discussions_to": "doc-sig@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "31-May-2001", "python_version": null, "post_history": "13-Jun-2001", "resolution": null, "requires": "256, 257", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0258/", "abstract": "\nAbstract\nThis PEP documents design issues and implementation details for\nDocutils, a Python Docstring Processing System (DPS). The rationale\nand high-level concepts of a DPS are documented in PEP 256, \"Docstring\nProcessing System Framework\". Also see PEP 256 for a\n\"Road Map to the Docstring PEPs\".\nDocutils is being designed modularly so that any of its components can\nbe replaced easily. In addition, Docutils is not limited to the\nprocessing of Python docstrings; it processes standalone documents as\nwell, in several contexts.\nNo changes to the core Python language are required by this PEP. Its\ndeliverables consist of a package for the standard library and its\ndocumentation.\n"}, | |
| {"id": "259", "title": "Omit printing newline after newline", "authors": "GvR", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "11-Jun-2001", "python_version": "2.2", "post_history": "11-Jun-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0259/", "abstract": "\nAbstract\nCurrently, the print statement always appends a newline, unless a\ntrailing comma is used. This means that if we want to print data\nthat already ends in a newline, we get two newlines, unless\nspecial precautions are taken.\nI propose to skip printing the newline when it follows a newline\nthat came from data.\nIn order to avoid having to add yet another magic variable to file\nobjects, I propose to give the existing 'softspace' variable an\nextra meaning: a negative value will mean \"the last data written\nended in a newline so no space or newline is required.\"\n"}, | |
| {"id": "260", "title": "Simplify xrange()", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Jun-2001", "python_version": "2.2", "post_history": "26-Jun-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0260/", "abstract": "\nAbstract\nThis PEP proposes to strip the xrange() object from some rarely\nused behavior like x[i:j] and x*n.\n"}, | |
| {"id": "261", "title": "Support for \"wide\" Unicode characters", "authors": "Prescod", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Jun-2001", "python_version": "2.2", "post_history": "27-Jun-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0261/", "abstract": "\nAbstract\nPython 2.1 unicode characters can have ordinals only up to 2**16 - 1.\nThis range corresponds to a range in Unicode known as the Basic\nMultilingual Plane. There are now characters in Unicode that live\non other \"planes\". The largest addressable character in Unicode\nhas the ordinal 17 * 2**16 - 1 (0x10ffff). For readability, we\nwill call this TOPCHAR and call characters in this range \"wide\ncharacters\".\n"}, | |
| {"id": "262", "title": "A Database of Installed Python Packages", "authors": "Kuchling", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "08-Jul-2001", "python_version": null, "post_history": "27-Mar-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0262/", "abstract": "\nIntroduction\nThis PEP describes a format for a database of the Python software\ninstalled on a system.\n(In this document, the term \"distribution\" is used to mean a set\nof code that's developed and distributed together. A \"distribution\"\nis the same as a Red Hat or Debian package, but the term \"package\"\nalready has a meaning in Python terminology, meaning \"a directory\nwith an __init__.py file in it.\")\n"}, | |
| {"id": "263", "title": "Defining Python Source Code Encodings", "authors": "Lemburg, von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "06-Jun-2001", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0263/", "abstract": "\nAbstract\nThis PEP proposes to introduce a syntax to declare the encoding of\na Python source file. The encoding information is then used by the\nPython parser to interpret the file using the given encoding. Most\nnotably this enhances the interpretation of Unicode literals in\nthe source code and makes it possible to write Unicode literals\nusing e.g. UTF-8 directly in an Unicode aware editor.\n"}, | |
| {"id": "264", "title": "Future statements in simulated shells", "authors": "Hudson", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Jul-2001", "python_version": "2.2", "post_history": "30-Jul-2001", "resolution": null, "requires": "236", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0264/", "abstract": "\nAbstract\nAs noted in PEP 236, there is no clear way for \"simulated\ninteractive shells\" to simulate the behaviour of __future__\nstatements in \"real\" interactive shells, i.e. have __future__\nstatements' effects last the life of the shell.\nThe PEP also takes the opportunity to clean up the other\nunresolved issue mentioned in PEP 236, the inability to stop\ncompile() inheriting the effect of future statements affecting the\ncode calling compile().\nThis PEP proposes to address the first problem by adding an\noptional fourth argument to the builtin function \"compile\", adding\ninformation to the _Feature instances defined in __future__.py and\nadding machinery to the standard library modules \"codeop\" and\n\"code\" to make the construction of such shells easy.\nThe second problem is dealt with by simply adding another\noptional argument to compile(), which if non-zero suppresses the\ninheriting of future statements' effects.\n"}, | |
| {"id": "265", "title": "Sorting Dictionaries by Value", "authors": "Griffin", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "08-Aug-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0265/", "abstract": "\nAbstract\nThis PEP suggests a \"sort by value\" operation for dictionaries.\nThe primary benefit would be in terms of \"batteries included\"\nsupport for a common Python idiom which, in its current form, is\nboth difficult for beginners to understand and cumbersome for all\nto implement.\n"}, | |
| {"id": "266", "title": "Optimizing Global Variable/Attribute Access", "authors": "Montanaro", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "13-Aug-2001", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0266/", "abstract": "\nIntroduction\nConsider the workhorse function sre_compile._compile. It is the internal\ncompilation function for the sre module. It consists almost entirely of a\nloop over the elements of the pattern being compiled, comparing opcodes with\nknown constant values and appending tokens to an output list. Most of the\ncomparisons are with constants imported from the sre_constants module.\nThis means there are lots of LOAD_GLOBAL bytecodes in the compiled output\nof this module. Just by reading the code it's apparent that the author\nintended LITERAL, NOT_LITERAL, OPCODES and many other symbols to\nbe constants. Still, each time they are involved in an expression, they must\nbe looked up anew.\nMost global accesses are actually to objects that are \"almost constants\".\nThis includes global variables in the current module as well as the attributes\nof other imported modules. Since they rarely change, it seems reasonable to\nplace the burden of updating references to such objects on the code that\nchanges the name bindings. If sre_constants.LITERAL is changed to refer\nto another object, perhaps it would be worthwhile for the code that modifies\nthe sre_constants module dict to correct any active references to that\nobject. By doing so, in many cases global variables and the attributes of\nmany objects could be cached as local variables. If the bindings between the\nnames given to the objects and the objects themselves changes rarely, the cost\nof keeping track of such objects should be low and the potential payoff fairly\nlarge.\nIn an attempt to gauge the effect of this proposal, I modified the Pystone\nbenchmark program included in the Python distribution to cache global\nfunctions. Its main function, Proc0, makes calls to ten different\nfunctions inside its for loop. In addition, Func2 calls Func1\nrepeatedly inside a loop. If local copies of these 11 global identifiers are\nmade before the functions' loops are entered, performance on this particular\nbenchmark improves by about two percent (from 5561 pystones to 5685 on my\nlaptop). It gives some indication that performance would be improved by\ncaching most global variable access. Note also that the pystone benchmark\nmakes essentially no accesses of global module attributes, an anticipated area\nof improvement for this PEP.\n"}, | |
| {"id": "267", "title": "Optimized Access to Module Namespaces", "authors": "Hylton", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "23-May-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0267/", "abstract": "\nIntroduction\nThis PEP proposes a new implementation of attribute access for\nmodule objects that optimizes access to module variables known at\ncompile time. The module will store these variables in an array\nand provide an interface to lookup attributes using array offsets.\nFor globals, builtins, and attributes of imported modules, the\ncompiler will generate code that uses the array offsets for fast\naccess.\n[describe the key parts of the design: dlict, compiler support,\nstupid name trick workarounds, optimization of other module's\nglobals]\nThe implementation will preserve existing semantics for module\nnamespaces, including the ability to modify module namespaces at\nruntime in ways that affect the visibility of builtin names.\n"}, | |
| {"id": "268", "title": "Extended HTTP functionality and WebDAV", "authors": "Stein", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "20-Aug-2001", "python_version": "2.x", "post_history": "21-Aug-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0268/", "abstract": "\nAbstract\nThis PEP discusses new modules and extended functionality for Python's\nHTTP support. Notably, the addition of authenticated requests, proxy\nsupport, authenticated proxy usage, and WebDAV capabilities.\n"}, | |
| {"id": "269", "title": "Pgen Module for Python", "authors": "Riehl", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "24-Aug-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0269/", "abstract": "\nAbstract\nMuch like the parser module exposes the Python parser, this PEP\nproposes that the parser generator used to create the Python\nparser, pgen, be exposed as a module in Python.\n"}, | |
| {"id": "270", "title": "uniq method for list objects", "authors": "Petrone", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "21-Aug-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0270/", "abstract": "\nAbstract\nThis PEP proposes adding a method for removing duplicate elements to\nthe list object.\n"}, | |
| {"id": "271", "title": "Prefixing sys.path by command line option", "authors": "Giacometti", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "15-Aug-2001", "python_version": "2.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0271/", "abstract": "\nAbstract\nAt present, setting the PYTHONPATH environment variable is the\nonly method for defining additional Python module search\ndirectories.\nThis PEP introduces the '-P' valued option to the python command\nas an alternative to PYTHONPATH.\n"}, | |
| {"id": "272", "title": "API for Block Encryption Algorithms v1.0", "authors": "Kuchling", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "18-Sep-2001", "python_version": null, "post_history": "17-Apr-2002, 29-May-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0272/", "abstract": "\nIntroduction\nEncryption algorithms transform their input data (called\nplaintext) in some way that is dependent on a variable key,\nproducing ciphertext. The transformation can easily be reversed\nif and only if one knows the key. The key is a sequence of bits\nchosen from some very large space of possible keys. There are two\nclasses of encryption algorithms: block ciphers and stream ciphers.\nBlock ciphers encrypt multibyte inputs of a fixed size (frequently\n8 or 16 bytes long), and can be operated in various feedback\nmodes. The feedback modes supported in this specification are:\n\n\nNumber\nConstant\nDescription\n\n\n\n1\nMODE_ECB\nElectronic Code Book\n\n2\nMODE_CBC\nCipher Block Chaining\n\n3\nMODE_CFB\nCipher Feedback\n\n5\nMODE_OFB\nOutput Feedback\n\n6\nMODE_CTR\nCounter\n\n\n\nThese modes are to be implemented as described in NIST publication\nSP 800-38A [1]. Descriptions of the first three feedback modes can\nalso be found in Bruce Schneier's book Applied Cryptography [2].\n(The numeric value 4 is reserved for MODE_PGP, a variant of CFB\ndescribed in RFC 2440: \"OpenPGP Message Format\". This mode\nisn't considered important enough to make it worth requiring it\nfor all block encryption ciphers, though supporting it is a nice\nextra feature.)\nIn a strict formal sense, stream ciphers encrypt data bit-by-bit;\npractically, stream ciphers work on a character-by-character\nbasis. This PEP only aims at specifying an interface for block\nciphers, though stream ciphers can support the interface described\nhere by fixing 'block_size' to 1. Feedback modes also don't make\nsense for stream ciphers, so the only reasonable feedback mode\nwould be ECB mode.\n"}, | |
| {"id": "273", "title": "Import Modules from Zip Archives", "authors": "Ahlstrom", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "11-Oct-2001", "python_version": "2.3", "post_history": "26-Oct-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0273/", "abstract": "\nAbstract\nThis PEP adds the ability to import Python modules\n*.py, *.py[co] and packages from zip archives. The\nsame code is used to speed up normal directory imports\nprovided os.listdir is available.\n"}, | |
| {"id": "274", "title": "Dict Comprehensions", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "25-Oct-2001", "python_version": "2.7, 3.0", "post_history": "29-Oct-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0274/", "abstract": "\nAbstract\nPEP 202 introduces a syntactical extension to Python called the\n\"list comprehension\". This PEP proposes a similar syntactical\nextension called the \"dictionary comprehension\" or \"dict\ncomprehension\" for short. You can use dict comprehensions in ways\nvery similar to list comprehensions, except that they produce\nPython dictionary objects instead of list objects.\n"}, | |
| {"id": "275", "title": "Switching on Multiple Values", "authors": "Lemburg", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "10-Nov-2001", "python_version": "2.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0275/", "abstract": "\nAbstract\nThis PEP proposes strategies to enhance Python's performance\nwith respect to handling switching on a single variable having\none of multiple possible values.\n"}, | |
| {"id": "276", "title": "Simple Iterator for ints", "authors": "Althoff", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "12-Nov-2001", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0276/", "abstract": "\nAbstract\nPython 2.1 added new functionality to support iterators (PEP 234).\nIterators have proven to be useful and convenient in many coding\nsituations. It is noted that the implementation of Python's\nfor-loop control structure uses the iterator protocol as of\nrelease 2.1. It is also noted that Python provides iterators for\nthe following builtin types: lists, tuples, dictionaries, strings,\nand files. This PEP proposes the addition of an iterator for the\nbuiltin type int (types.IntType). Such an iterator would simplify\nthe coding of certain for-loops in Python.\n"}, | |
| {"id": "277", "title": "Unicode file name support for Windows NT", "authors": "Hodgson", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "11-Jan-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0277/", "abstract": "\nAbstract\nThis PEP discusses supporting access to all files possible on\nWindows NT by passing Unicode file names directly to the system's\nwide-character functions.\n"}, | |
| {"id": "278", "title": "Universal Newline Support", "authors": "Jansen", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "14-Jan-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0278/", "abstract": "\nAbstract\nThis PEP discusses a way in which Python can support I/O on files\nwhich have a newline format that is not the native format on the\nplatform, so that Python on each platform can read and import\nfiles with CR (Macintosh), LF (Unix) or CR LF (Windows) line\nendings.\nIt is more and more common to come across files that have an end\nof line that does not match the standard on the current platform:\nfiles downloaded over the net, remotely mounted filesystems on a\ndifferent platform, Mac OS X with its double standard of Mac and\nUnix line endings, etc.\nMany tools such as editors and compilers already handle this\ngracefully, it would be good if Python did so too.\n"}, | |
| {"id": "279", "title": "The enumerate() built-in function", "authors": "Hettinger", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Jan-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0279/", "abstract": "\nAbstract\nThis PEP introduces a new built-in function, enumerate() to\nsimplify a commonly used looping idiom. It provides all iterable\ncollections with the same advantage that iteritems() affords to\ndictionaries - a compact, readable, reliable index notation.\n"}, | |
| {"id": "280", "title": "Optimizing access to globals", "authors": "GvR", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "10-Feb-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0280/", "abstract": "\nAbstract\nThis PEP describes yet another approach to optimizing access to\nmodule globals, providing an alternative to PEP 266 (Optimizing\nGlobal Variable/Attribute Access by Skip Montanaro) and PEP 267\n(Optimized Access to Module Namespaces by Jeremy Hylton).\nThe expectation is that eventually one approach will be picked and\nimplemented; possibly multiple approaches will be prototyped\nfirst.\n"}, | |
| {"id": "281", "title": "Loop Counter Iteration with range and xrange", "authors": "Hetland", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "11-Feb-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0281/", "abstract": "\nAbstract\nThis PEP describes yet another way of exposing the loop counter in\nfor-loops. It basically proposes that the functionality of the\nfunction indices() from PEP 212 be included in the existing\nfunctions range() and xrange().\n"}, | |
| {"id": "282", "title": "A Logging System", "authors": "Sajip, Mick", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "04-Feb-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0282/", "abstract": "\nAbstract\nThis PEP describes a proposed logging package for Python's\nstandard library.\nBasically the system involves the user creating one or more logger\nobjects on which methods are called to log debugging notes,\ngeneral information, warnings, errors etc. Different logging\n'levels' can be used to distinguish important messages from less\nimportant ones.\nA registry of named singleton logger objects is maintained so that\n\ndifferent logical logging streams (or 'channels') exist\n(say, one for 'zope.zodb' stuff and another for\n'mywebsite'-specific stuff)\none does not have to pass logger object references around.\n\nThe system is configurable at runtime. This configuration\nmechanism allows one to tune the level and type of logging done\nwhile not touching the application itself.\n"}, | |
| {"id": "283", "title": "Python 2.3 Release Schedule", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "27-Feb-2002", "python_version": "2.3", "post_history": "27-Feb-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0283/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 2.3. The schedule primarily concerns itself with PEP-sized\nitems. Small features may be added up to and including the first\nbeta release. Bugs may be fixed until the final release.\nThere will be at least two alpha releases, two beta releases, and\none release candidate. Alpha and beta releases will be spaced at\nleast 4 weeks apart (except if an emergency release must be made\nto correct a blunder in the previous release; then the blunder\nrelease does not count). Release candidates will be spaced at\nleast one week apart (excepting again blunder corrections).\n\n\nalpha 1\n31 Dec 2002\n\nalpha 2\n19 Feb 2003\n\nbeta 1\n25 Apr 2003\n\nbeta 2\n29 Jun 2003\n\ncandidate 1\n18 Jul 2003\n\ncandidate 2\n24 Jul 2003\n\nfinal\n29 Jul 2003\n\n\n\n"}, | |
| {"id": "284", "title": "Integer for-loops", "authors": "Eppstein, Ewing", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "01-Mar-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0284/", "abstract": "\nAbstract\nThis PEP proposes to simplify iteration over intervals of\nintegers, by extending the range of expressions allowed after a\n\"for\" keyword to allow three-way comparisons such as\nfor lower <= var < upper:\n\n\nin place of the current\nfor item in list:\n\n\nsyntax. The resulting loop or list iteration will loop over all\nvalues of var that make the comparison true, starting from the\nleft endpoint of the given interval.\n"}, | |
| {"id": "285", "title": "Adding a bool type", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "08-Mar-2002", "python_version": "2.3", "post_history": "08-Mar-2002, 30-Mar-2002, 03-Apr-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0285/", "abstract": "\nAbstract\nThis PEP proposes the introduction of a new built-in type, bool,\nwith two constants, False and True. The bool type would be a\nstraightforward subtype (in C) of the int type, and the values\nFalse and True would behave like 0 and 1 in most respects (for\nexample, False==0 and True==1 would be true) except repr() and\nstr(). All built-in operations that conceptually return a Boolean\nresult will be changed to return False or True instead of 0 or 1;\nfor example, comparisons, the \"not\" operator, and predicates like\nisinstance().\n"}, | |
| {"id": "286", "title": "Enhanced Argument Tuples", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "03-Mar-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0286/", "abstract": "\nAbstract\nPyArg_ParseTuple is confronted with difficult memory management if\nan argument converter creates new memory. To deal with these\ncases, a specialized argument type is proposed.\n"}, | |
| {"id": "287", "title": "reStructuredText Docstring Format", "authors": "Goodger", "discussions_to": "doc-sig@python.org", "status": "Active", "type": "Informational", "topic": "", "created": "25-Mar-2002", "python_version": null, "post_history": "02-Apr-2002", "resolution": null, "requires": null, "replaces": "216", "superseded_by": null, "url": "https://peps.python.org/pep-0287/", "abstract": "\nAbstract\nWhen plaintext hasn't been expressive enough for inline documentation,\nPython programmers have sought out a format for docstrings. This PEP\nproposes that the reStructuredText markup be adopted as a standard\nmarkup format for structured plaintext documentation in Python\ndocstrings, and for PEPs and ancillary documents as well.\nreStructuredText is a rich and extensible yet easy-to-read,\nwhat-you-see-is-what-you-get plaintext markup syntax.\nOnly the low-level syntax of docstrings is addressed here. This PEP\nis not concerned with docstring semantics or processing at all (see\nPEP 256 for a \"Road Map to the Docstring PEPs\"). Nor is it an attempt\nto deprecate pure plaintext docstrings, which are always going to be\nlegitimate. The reStructuredText markup is an alternative for those\nwho want more expressive docstrings.\n"}, | |
| {"id": "288", "title": "Generators Attributes and Exceptions", "authors": "Hettinger", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "21-Mar-2002", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0288/", "abstract": "\nAbstract\nThis PEP proposes to enhance generators by providing mechanisms for\nraising exceptions and sharing data with running generators.\n"}, | |
| {"id": "289", "title": "Generator Expressions", "authors": "Hettinger", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Jan-2002", "python_version": "2.4", "post_history": "22-Oct-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0289/", "abstract": "\nAbstract\nThis PEP introduces generator expressions as a high performance,\nmemory efficient generalization of list comprehensions PEP 202 and\ngenerators PEP 255.\n"}, | |
| {"id": "290", "title": "Code Migration and Modernization", "authors": "Hettinger", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "06-Jun-2002", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0290/", "abstract": "\nAbstract\nThis PEP is a collection of procedures and ideas for updating Python\napplications when newer versions of Python are installed.\nThe migration tips highlight possible areas of incompatibility and\nmake suggestions on how to find and resolve those differences. The\nmodernization procedures show how older code can be updated to take\nadvantage of new language features.\n"}, | |
| {"id": "291", "title": "Backward Compatibility for the Python 2 Standard Library", "authors": "Norwitz", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "06-Jun-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0291/", "abstract": "\nAbstract\nThis PEP describes the packages and modules in the Python 2\nstandard library which should remain backward compatible with\nprevious versions of Python. If a package is not listed here,\nthen it need only remain compatible with the version of Python it\nis distributed with.\nThis PEP has no bearing on the Python 3 standard library.\n"}, | |
| {"id": "292", "title": "Simpler String Substitutions", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "18-Jun-2002", "python_version": "2.4", "post_history": "18-Jun-2002, 23-Mar-2004, 22-Aug-2004", "resolution": null, "requires": null, "replaces": "215", "superseded_by": null, "url": "https://peps.python.org/pep-0292/", "abstract": "\nAbstract\nThis PEP describes a simpler string substitution feature, also\nknown as string interpolation. This PEP is \"simpler\" in two\nrespects:\n\nPython's current string substitution feature\n(i.e. %-substitution) is complicated and error prone. This PEP\nis simpler at the cost of some expressiveness.\nPEP 215 proposed an alternative string interpolation feature,\nintroducing a new $ string prefix. PEP 292 is simpler than\nthis because it involves no syntax changes and has much simpler\nrules for what substitutions can occur in the string.\n\n"}, | |
| {"id": "293", "title": "Codec Error Handling Callbacks", "authors": "D\u00f6rwald", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "18-Jun-2002", "python_version": "2.3", "post_history": "19-Jun-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0293/", "abstract": "\nAbstract\nThis PEP aims at extending Python's fixed codec error handling\nschemes with a more flexible callback based approach.\nPython currently uses a fixed error handling for codec error\nhandlers. This PEP describes a mechanism which allows Python to\nuse function callbacks as error handlers. With these more\nflexible error handlers it is possible to add new functionality to\nexisting codecs by e.g. providing fallback solutions or different\nencodings for cases where the standard codec mapping does not\napply.\n"}, | |
| {"id": "294", "title": "Type Names in the types Module", "authors": "Tirosh", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "19-Jun-2002", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0294/", "abstract": "\nAbstract\nThis PEP proposes that symbols matching the type name should be added\nto the types module for all basic Python types in the types module:\ntypes.IntegerType -> types.int\ntypes.FunctionType -> types.function\ntypes.TracebackType -> types.traceback\n ...\n\n\nThe long capitalized names currently in the types module will be\ndeprecated.\nWith this change the types module can serve as a replacement for the\nnew module. The new module shall be deprecated and listed in PEP 4.\n"}, | |
| {"id": "295", "title": "Interpretation of multiline string constants", "authors": "Koltsov", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "22-Jul-2002", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0295/", "abstract": "\nAbstract\nThis PEP describes an interpretation of multiline string constants\nfor Python. It suggests stripping spaces after newlines and\nstripping a newline if it is first character after an opening\nquotation.\n"}, | |
| {"id": "296", "title": "Adding a bytes Object Type", "authors": "Gilbert", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "12-Jul-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0296/", "abstract": "\nAbstract\nThis PEP proposes the creation of a new standard type and builtin\nconstructor called 'bytes'. The bytes object is an efficiently\nstored array of bytes with some additional characteristics that\nset it apart from several implementations that are similar.\n"}, | |
| {"id": "297", "title": "Support for System Upgrades", "authors": "Lemburg", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "19-Jul-2001", "python_version": "2.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0297/", "abstract": "\nAbstract\nThis PEP proposes strategies to allow the Python standard library\nto be upgraded in parts without having to reinstall the complete\ndistribution or having to wait for a new patch level release.\n"}, | |
| {"id": "298", "title": "The Locked Buffer Interface", "authors": "Heller", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "26-Jul-2002", "python_version": "2.3", "post_history": "30-Jul-2002, 01-Aug-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0298/", "abstract": "\nAbstract\nThis PEP proposes an extension to the buffer interface called the\n'locked buffer interface'.\nThe locked buffer interface avoids the flaws of the 'old' buffer\ninterface [1] as defined in Python versions up to and including\n2.2, and has the following semantics:\n\nThe lifetime of the retrieved pointer is clearly defined and\ncontrolled by the client.\nThe buffer size is returned as a 'size_t' data type, which\nallows access to large buffers on platforms where sizeof(int)\n!= sizeof(void *).\n\n(Guido comments: This second sounds like a change we could also\nmake to the \"old\" buffer interface, if we introduce another flag\nbit that's not part of the default flags.)\n"}, | |
| {"id": "299", "title": "Special __main__() function in modules", "authors": "Epler", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "12-Aug-2002", "python_version": "2.3", "post_history": "29-Mar-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0299/", "abstract": "\nAbstract\nMany Python modules are also intended to be callable as standalone\nscripts. This PEP proposes that a special function called __main__()\nshould serve this purpose.\n"}, | |
| {"id": "301", "title": "Package Index and Metadata for Distutils", "authors": "Jones", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "24-Oct-2002", "python_version": "2.3", "post_history": "08-Nov-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0301/", "abstract": "\nAbstract\nThis PEP proposes several extensions to the Distutils packaging system\n[1]. These enhancements include a central package index server,\ntools for submitting package information to the index and extensions\nto the package metadata to include Trove [2] information.\nThis PEP does not address issues of package dependency. It also does\nnot address storage and download of packages as described in PEP 243.\nNor is it proposing a local database of packages as described\nin PEP 262.\nExisting package repositories such as the Vaults of Parnassus [3],\nCPAN [4] and PAUSE [5] will be investigated as prior art in this\nfield.\n"}, | |
| {"id": "302", "title": "New Import Hooks", "authors": "JvR, Moore", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Dec-2002", "python_version": "2.3", "post_history": "19-Dec-2002", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0302/", "abstract": "\nAbstract\nThis PEP proposes to add a new set of import hooks that offer better\ncustomization of the Python import mechanism. Contrary to the current\n__import__ hook, a new-style hook can be injected into the existing\nscheme, allowing for a finer grained control of how modules are found and how\nthey are loaded.\n"}, | |
| {"id": "303", "title": "Extend divmod() for Multiple Divisors", "authors": "Bellman", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "31-Dec-2002", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0303/", "abstract": "\nAbstract\nThis PEP describes an extension to the built-in divmod() function,\nallowing it to take multiple divisors, chaining several calls to\ndivmod() into one.\n"}, | |
| {"id": "304", "title": "Controlling Generation of Bytecode Files", "authors": "Montanaro", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "22-Jan-2003", "python_version": null, "post_history": "27-Jan-2003, 31-Jan-2003, 17-Jun-2005", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0304/", "abstract": "\nAbstract\nThis PEP outlines a mechanism for controlling the generation and\nlocation of compiled Python bytecode files. This idea originally\narose as a patch request [1] and evolved into a discussion thread on\nthe python-dev mailing list [2]. The introduction of an environment\nvariable will allow people installing Python or Python-based\nthird-party packages to control whether or not bytecode files should\nbe generated at installation time, and if so, where they should be\nwritten. It will also allow users to control whether or not bytecode\nfiles should be generated at application run-time, and if so, where\nthey should be written.\n"}, | |
| {"id": "305", "title": "CSV File API", "authors": "Altis, Cole, McNamara, Montanaro, Wells", "discussions_to": "csv@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Jan-2003", "python_version": "2.3", "post_history": "31-Jan-2003, 13-Feb-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0305/", "abstract": "\nAbstract\nThe Comma Separated Values (CSV) file format is the most common import\nand export format for spreadsheets and databases. Although many CSV\nfiles are simple to parse, the format is not formally defined by a\nstable specification and is subtle enough that parsing lines of a CSV\nfile with something like line.split(\",\") is eventually bound to\nfail. This PEP defines an API for reading and writing CSV files. It\nis accompanied by a corresponding module which implements the API.\n"}, | |
| {"id": "306", "title": "How to Change Python's Grammar", "authors": "Hudson, Diederich, Coghlan, Peterson", "discussions_to": null, "status": "Withdrawn", "type": "Informational", "topic": "", "created": "29-Jan-2003", "python_version": null, "post_history": "30-Jan-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0306/", "abstract": "\nAbstract\nThere's more to changing Python's grammar than editing\nGrammar/Grammar and Python/compile.c. This PEP aims to be a\nchecklist of places that must also be fixed.\nIt is probably incomplete. If you see omissions, just add them if\nyou can - you are not going to offend the author's sense of\nownership. Otherwise submit a bug or patch and assign it to mwh.\nThis PEP is not intended to be an instruction manual on Python\ngrammar hacking, for several reasons.\n"}, | |
| {"id": "307", "title": "Extensions to the pickle protocol", "authors": "GvR, Peters", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "31-Jan-2003", "python_version": "2.3", "post_history": "07-Feb-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0307/", "abstract": "\nIntroduction\nPickling new-style objects in Python 2.2 is done somewhat clumsily\nand causes pickle size to bloat compared to classic class\ninstances. This PEP documents a new pickle protocol in Python 2.3\nthat takes care of this and many other pickle issues.\nThere are two sides to specifying a new pickle protocol: the byte\nstream constituting pickled data must be specified, and the\ninterface between objects and the pickling and unpickling engines\nmust be specified. This PEP focuses on API issues, although it\nmay occasionally touch on byte stream format details to motivate a\nchoice. The pickle byte stream format is documented formally by\nthe standard library module pickletools.py (already checked into\nCVS for Python 2.3).\nThis PEP attempts to fully document the interface between pickled\nobjects and the pickling process, highlighting additions by\nspecifying \"new in this PEP\". (The interface to invoke pickling\nor unpickling is not covered fully, except for the changes to the\nAPI for specifying the pickling protocol to picklers.)\n"}, | |
| {"id": "308", "title": "Conditional Expressions", "authors": "GvR, Hettinger", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "07-Feb-2003", "python_version": "2.5", "post_history": "07-Feb-2003, 11-Feb-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0308/", "abstract": ""}, | |
| {"id": "309", "title": "Partial Function Application", "authors": "Harris", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "08-Feb-2003", "python_version": "2.5", "post_history": "10-Feb-2003, 27-Feb-2003, 22-Feb-2004, 28-Apr-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0309/", "abstract": "\nAbstract\nThis proposal is for a function or callable class that allows a new\ncallable to be constructed from a callable and a partial argument list\n(including positional and keyword arguments).\nI propose a standard library module called \"functional\", to hold\nuseful higher-order functions, including the implementation of\npartial().\nAn implementation has been submitted to SourceForge [2].\n"}, | |
| {"id": "310", "title": "Reliable Acquisition/Release Pairs", "authors": "Hudson, Moore", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "18-Dec-2002", "python_version": "2.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0310/", "abstract": "\nAbstract\nIt would be nice to have a less typing-intense way of writing:\nthe_lock.acquire()\ntry:\n ....\nfinally:\n the_lock.release()\n\n\nThis PEP proposes a piece of syntax (a 'with' block) and a\n\"small-i\" interface that generalizes the above.\n"}, | |
| {"id": "311", "title": "Simplified Global Interpreter Lock Acquisition for Extensions", "authors": "Hammond", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Feb-2003", "python_version": "2.3", "post_history": "05-Feb-2003, 14-Feb-2003, 19-Apr-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0311/", "abstract": "\nAbstract\nThis PEP proposes a simplified API for access to the Global\nInterpreter Lock (GIL) for Python extension modules.\nSpecifically, it provides a solution for authors of complex\nmulti-threaded extensions, where the current state of Python\n(i.e., the state of the GIL is unknown.\nThis PEP proposes a new API, for platforms built with threading\nsupport, to manage the Python thread state. An implementation\nstrategy is proposed, along with an initial, platform independent\nimplementation.\n"}, | |
| {"id": "312", "title": "Simple Implicit Lambda", "authors": "Suzi, Martelli", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "11-Feb-2003", "python_version": "2.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0312/", "abstract": "\nAbstract\nThis PEP proposes to make argumentless lambda keyword optional in\nsome cases where it is not grammatically ambiguous.\n"}, | |
| {"id": "313", "title": "Adding Roman Numeral Literals to Python", "authors": "Meyer", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "01-Apr-2003", "python_version": "2.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0313/", "abstract": "\nAbstract\nThis PEP (also known as PEP CCCXIII) proposes adding Roman\nnumerals as a literal type. It also proposes the new built-in\nfunction \"roman\", which converts an object to an integer, then\nconverts the integer to a string that is the Roman numeral literal\nequivalent to the integer.\n"}, | |
| {"id": "314", "title": "Metadata for Python Software Packages 1.1", "authors": "Kuchling, Jones", "discussions_to": "distutils-sig@python.org", "status": "Superseded", "type": "Standards Track", "topic": "packaging", "created": "12-Apr-2003", "python_version": "2.5", "post_history": "29-Apr-2003", "resolution": null, "requires": null, "replaces": "241", "superseded_by": "345", "url": "https://peps.python.org/pep-0314/", "abstract": "\nIntroduction\nThis PEP describes a mechanism for adding metadata to Python\npackages. It includes specifics of the field names, and their\nsemantics and usage.\nThis document specifies version 1.1 of the metadata format.\nVersion 1.0 is specified in PEP 241.\n"}, | |
| {"id": "315", "title": "Enhanced While Loop", "authors": "Hettinger, Carroll", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "25-Apr-2003", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0315/", "abstract": "\nAbstract\nThis PEP proposes adding an optional \"do\" clause to the beginning\nof the while loop to make loop code clearer and reduce errors\ncaused by code duplication.\n"}, | |
| {"id": "316", "title": "Programming by Contract for Python", "authors": "Way", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "02-May-2003", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0316/", "abstract": "\nAbstract\nThis submission describes programming by contract for Python.\nEiffel's Design By Contract(tm) is perhaps the most popular use of\nprogramming contracts [2].\nProgramming contracts extends the language to include invariant\nexpressions for classes and modules, and pre- and post-condition\nexpressions for functions and methods.\nThese expressions (contracts) are similar to assertions: they must be\ntrue or the program is stopped, and run-time checking of the contracts\nis typically only enabled while debugging. Contracts are higher-level\nthan straight assertions and are typically included in documentation.\n"}, | |
| {"id": "317", "title": "Eliminate Implicit Exception Instantiation", "authors": "Taschuk", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "06-May-2003", "python_version": "2.4", "post_history": "09-Jun-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0317/", "abstract": "\nAbstract\n\n\"For clarity in new code, the form raise class(argument, ...)\nis recommended (i.e. make an explicit call to the constructor).\"--Guido van Rossum, in 1997 [1]\n\nThis PEP proposes the formal deprecation and eventual elimination of\nforms of the raise statement which implicitly instantiate an\nexception. For example, statements such as\nraise HullBreachError\nraise KitchenError, 'all out of baked beans'\n\n\nmust under this proposal be replaced with their synonyms\nraise HullBreachError()\nraise KitchenError('all out of baked beans')\n\n\nNote that these latter statements are already legal, and that this PEP\ndoes not change their meaning.\nEliminating these forms of raise makes it impossible to use string\nexceptions; accordingly, this PEP also proposes the formal deprecation\nand eventual elimination of string exceptions.\nAdoption of this proposal breaks backwards compatibility. Under the\nproposed implementation schedule, Python 2.4 will introduce warnings\nabout uses of raise which will eventually become incorrect, and\nPython 3.0 will eliminate them entirely. (It is assumed that this\ntransition period - 2.4 to 3.0 - will be at least one year long, to\ncomply with the guidelines of PEP 5.)\n"}, | |
| {"id": "318", "title": "Decorators for Functions and Methods", "authors": "Smith", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Jun-2003", "python_version": "2.4", "post_history": "09-Jun-2003, 10-Jun-2003, 27-Feb-2004, 23-Mar-2004, 30-Aug-2004, 02-Sep-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0318/", "abstract": "\nAbstract\nThe current method for transforming functions and methods (for instance,\ndeclaring them as a class or static method) is awkward and can lead to\ncode that is difficult to understand. Ideally, these transformations\nshould be made at the same point in the code where the declaration\nitself is made. This PEP introduces new syntax for transformations of a\nfunction or method declaration.\n"}, | |
| {"id": "319", "title": "Python Synchronize/Asynchronize Block", "authors": "Pelletier", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "24-Feb-2003", "python_version": "2.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0319/", "abstract": "\nAbstract\nThis PEP proposes adding two new keywords to Python, 'synchronize'\nand 'asynchronize'.\n"}, | |
| {"id": "320", "title": "Python 2.4 Release Schedule", "authors": "Warsaw, Hettinger, Baxter", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "29-Jul-2003", "python_version": "2.4", "post_history": "01-Dec-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0320/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 2.4. The schedule primarily concerns itself with PEP-sized\nitems. Small features may be added up to and including the first\nbeta release. Bugs may be fixed until the final release.\nThere will be at least two alpha releases, two beta releases, and\none release candidate. The release date was 30th November, 2004.\n"}, | |
| {"id": "321", "title": "Date/Time Parsing and Formatting", "authors": "Kuchling", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "16-Sep-2003", "python_version": "2.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0321/", "abstract": "\nAbstract\nPython 2.3 added a number of simple date and time types in the\ndatetime module. There's no support for parsing strings in various\nformats and returning a corresponding instance of one of the types.\nThis PEP proposes adding a family of predefined parsing function for\nseveral commonly used date and time formats, and a facility for generic\nparsing.\nThe types provided by the datetime module all have\n.isoformat() and .ctime() methods that return string\nrepresentations of a time, and the .strftime() method can be used\nto construct new formats. There are a number of additional\ncommonly-used formats that would be useful to have as part of the\nstandard library; this PEP also suggests how to add them.\n"}, | |
| {"id": "322", "title": "Reverse Iteration", "authors": "Hettinger", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "24-Sep-2003", "python_version": "2.4", "post_history": "24-Sep-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0322/", "abstract": "\nAbstract\nThis proposal is to add a builtin function to support reverse\niteration over sequences.\n"}, | |
| {"id": "323", "title": "Copyable Iterators", "authors": "Martelli", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "25-Oct-2003", "python_version": "2.5", "post_history": "29-Oct-2003", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0323/", "abstract": "\nAbstract\nThis PEP suggests that some iterator types should support shallow\ncopies of their instances by exposing a __copy__ method which meets\nsome specific requirements, and indicates how code using an iterator\nmight exploit such a __copy__ method when present.\n"}, | |
| {"id": "324", "title": "subprocess - New process module", "authors": "Astrand", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Nov-2003", "python_version": "2.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0324/", "abstract": "\nAbstract\nThis PEP describes a new module for starting and communicating\nwith processes.\n"}, | |
| {"id": "325", "title": "Resource-Release Support for Generators", "authors": "Pedroni", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "25-Aug-2003", "python_version": "2.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0325/", "abstract": "\nAbstract\nGenerators allow for natural coding and abstraction of traversal\nover data. Currently if external resources needing proper timely\nrelease are involved, generators are unfortunately not adequate.\nThe typical idiom for timely release is not supported, a yield\nstatement is not allowed in the try clause of a try-finally\nstatement inside a generator. The finally clause execution can be\nneither guaranteed nor enforced.\nThis PEP proposes that the built-in generator type implement a\nclose method and destruction semantics, such that the restriction\non yield placement can be lifted, expanding the applicability of\ngenerators.\n"}, | |
| {"id": "326", "title": "A Case for Top and Bottom Values", "authors": "Carlson, Reedy", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "20-Dec-2003", "python_version": "2.4", "post_history": "20-Dec-2003, 03-Jan-2004, 05-Jan-2004, 07-Jan-2004, 21-Feb-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0326/", "abstract": "\nAbstract\nThis PEP proposes two singleton constants that represent a top and\nbottom [3] value: Max and Min (or two similarly suggestive\nnames [4]; see Open Issues).\nAs suggested by their names, Max and Min would compare higher\nor lower than any other object (respectively). Such behavior results\nin easier to understand code and fewer special cases in which a\ntemporary minimum or maximum value is required, and an actual minimum\nor maximum numeric value is not limited.\n"}, | |
| {"id": "327", "title": "Decimal Data Type", "authors": "Batista", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "17-Oct-2003", "python_version": "2.4", "post_history": "30-Nov-2003, 02-Jan-2004, 29-Jan-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0327/", "abstract": "\nAbstract\nThe idea is to have a Decimal data type, for every use where decimals\nare needed but binary floating point is too inexact.\nThe Decimal data type will support the Python standard functions and\noperations, and must comply with the decimal arithmetic ANSI standard\nX3.274-1996 [1].\nDecimal will be floating point (as opposed to fixed point) and will\nhave bounded precision (the precision is the upper limit on the\nnumber of significant digits in a result). However, precision is\nuser-settable, and a notion of significant trailing zeroes is supported\nso that fixed-point usage is also possible.\nThis work is based on code and test functions written by Eric Price,\nAahz and Tim Peters. Just before Python 2.4a1, the decimal.py\nreference implementation was moved into the standard library; along\nwith the documentation and the test suite, this was the work of\nRaymond Hettinger. Much of the explanation in this PEP is taken from\nCowlishaw's work [2], comp.lang.python and python-dev.\n"}, | |
| {"id": "328", "title": "Imports: Multi-Line and Absolute/Relative", "authors": "Aahz", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "21-Dec-2003", "python_version": "2.4, 2.5, 2.6", "post_history": "08-Mar-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0328/", "abstract": "\nAbstract\nThe import statement has two problems:\n\nLong import statements can be difficult to write, requiring\nvarious contortions to fit Pythonic style guidelines.\nImports can be ambiguous in the face of packages; within a package,\nit's not clear whether import foo refers to a module within the\npackage or some module outside the package. (More precisely, a local\nmodule or package can shadow another hanging directly off\nsys.path.)\n\nFor the first problem, it is proposed that parentheses be permitted to\nenclose multiple names, thus allowing Python's standard mechanisms for\nmulti-line values to apply. For the second problem, it is proposed that\nall import statements be absolute by default (searching sys.path\nonly) with special syntax (leading dots) for accessing package-relative\nimports.\n"}, | |
| {"id": "329", "title": "Treating Builtins as Constants in the Standard Library", "authors": "Hettinger", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "18-Apr-2004", "python_version": "2.4", "post_history": "18-Apr-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0329/", "abstract": "\nAbstract\nThe proposal is to add a function for treating builtin references as\nconstants and to apply that function throughout the standard library.\n"}, | |
| {"id": "330", "title": "Python Bytecode Verification", "authors": "Pelletier", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "17-Jun-2004", "python_version": "2.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0330/", "abstract": "\nAbstract\nIf Python Virtual Machine (PVM) bytecode is not \"well-formed\" it\nis possible to crash or exploit the PVM by causing various errors\nsuch as under/overflowing the value stack or reading/writing into\narbitrary areas of the PVM program space. Most of these kinds of\nerrors can be eliminated by verifying that PVM bytecode does not\nviolate a set of simple constraints before execution.\nThis PEP proposes a set of constraints on the format and structure\nof Python Virtual Machine (PVM) bytecode and provides an\nimplementation in Python of this verification process.\n"}, | |
| {"id": "331", "title": "Locale-Independent Float/String Conversions", "authors": "Reis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Jul-2003", "python_version": "2.4", "post_history": "21-Jul-2003, 13-Aug-2003, 18-Jun-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0331/", "abstract": "\nIntroduction\nPython provides generic localization services through the locale\nmodule, which among other things allows localizing the display and\nconversion process of numeric types. Locale categories, such as\nLC_TIME and LC_COLLATE, allow configuring precisely what aspects\nof the application are to be localized.\nThe LC_NUMERIC category specifies formatting for non-monetary\nnumeric information, such as the decimal separator in float and\nfixed-precision numbers. Localization of the LC_NUMERIC category\nis currently implemented only in Python-space; C libraries invoked\nfrom the Python runtime are unaware of Python's LC_NUMERIC\nsetting. This is done to avoid changing the behavior of certain\nlow-level functions that are used by the Python parser and related\ncode [2].\nHowever, this presents a problem for extension modules that wrap C\nlibraries. Applications that use these extension modules will\ninconsistently display and convert floating-point values.\nJames Henstridge, the author of PyGTK [3], has additionally\npointed out that the setlocale() function also presents\nthread-safety issues, since a thread may call the C library\nsetlocale() outside of the GIL, and cause Python to parse and\ngenerate floats incorrectly.\n"}, | |
| {"id": "332", "title": "Byte vectors and String/Unicode Unification", "authors": "Montanaro", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "11-Aug-2004", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0332/", "abstract": "\nAbstract\nThis PEP outlines the introduction of a raw bytes sequence object\nand the unification of the current str and unicode objects.\n"}, | |
| {"id": "333", "title": "Python Web Server Gateway Interface v1.0", "authors": "Eby", "discussions_to": "web-sig@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "07-Dec-2003", "python_version": null, "post_history": "07-Dec-2003, 08-Aug-2004, 20-Aug-2004, 27-Aug-2004, 27-Sep-2010", "resolution": null, "requires": null, "replaces": null, "superseded_by": "3333", "url": "https://peps.python.org/pep-0333/", "abstract": "\nAbstract\nThis document specifies a proposed standard interface between web\nservers and Python web applications or frameworks, to promote web\napplication portability across a variety of web servers.\n"}, | |
| {"id": "334", "title": "Simple Coroutines via SuspendIteration", "authors": "Evans", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "26-Aug-2004", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0334/", "abstract": "\nAbstract\nAsynchronous application frameworks such as Twisted [1] and Peak\n[2], are based on a cooperative multitasking via event queues or\ndeferred execution. While this approach to application development\ndoes not involve threads and thus avoids a whole class of problems\n[3], it creates a different sort of programming challenge. When an\nI/O operation would block, a user request must suspend so that other\nrequests can proceed. The concept of a coroutine [4] promises to\nhelp the application developer grapple with this state management\ndifficulty.\nThis PEP proposes a limited approach to coroutines based on an\nextension to the iterator protocol. Currently, an iterator may\nraise a StopIteration exception to indicate that it is done producing\nvalues. This proposal adds another exception to this protocol,\nSuspendIteration, which indicates that the given iterator may have\nmore values to produce, but is unable to do so at this time.\n"}, | |
| {"id": "335", "title": "Overloadable Boolean Operators", "authors": "Ewing", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "29-Aug-2004", "python_version": "3.3", "post_history": "05-Sep-2004, 30-Sep-2011, 25-Oct-2011", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0335/", "abstract": "\nAbstract\nThis PEP proposes an extension to permit objects to define their own\nmeanings for the boolean operators 'and', 'or' and 'not', and suggests\nan efficient strategy for implementation. A prototype of this\nimplementation is available for download.\n"}, | |
| {"id": "336", "title": "Make None Callable", "authors": "McClelland", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "28-Oct-2004", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0336/", "abstract": "\nAbstract\nNone should be a callable object that when called with any\narguments has no side effect and returns None.\n"}, | |
| {"id": "337", "title": "Logging Usage in the Standard Library", "authors": "Dubner", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "02-Oct-2004", "python_version": "2.5", "post_history": "10-Nov-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0337/", "abstract": "\nAbstract\nThis PEP defines a standard for using the logging system (PEP 282) in the\nstandard library.\nImplementing this PEP will simplify development of daemon\napplications. As a downside this PEP requires slight\nmodifications (however in a back-portable way) to a large number\nof standard modules.\nAfter implementing this PEP one can use following filtering\nscheme:\nlogging.getLogger('py.BaseHTTPServer').setLevel(logging.FATAL)\n\n\n"}, | |
| {"id": "338", "title": "Executing modules as scripts", "authors": "Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-Oct-2004", "python_version": "2.5", "post_history": "08-Nov-2004, 11-Feb-2006, 12-Feb-2006, 18-Feb-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0338/", "abstract": "\nAbstract\nThis PEP defines semantics for executing any Python module as a\nscript, either with the -m command line switch, or by invoking\nit via runpy.run_module(modulename).\nThe -m switch implemented in Python 2.4 is quite limited. This\nPEP proposes making use of the PEP 302 import hooks to allow any\nmodule which provides access to its code object to be executed.\n"}, | |
| {"id": "339", "title": "Design of the CPython Compiler", "authors": "Cannon", "discussions_to": null, "status": "Withdrawn", "type": "Informational", "topic": "", "created": "02-Feb-2005", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0339/", "abstract": "\nAbstract\nHistorically (through 2.4), compilation from source code to bytecode\ninvolved two steps:\n\nParse the source code into a parse tree (Parser/pgen.c)\nEmit bytecode based on the parse tree (Python/compile.c)\n\nHistorically, this is not how a standard compiler works. The usual\nsteps for compilation are:\n\nParse source code into a parse tree (Parser/pgen.c)\nTransform parse tree into an Abstract Syntax Tree (Python/ast.c)\nTransform AST into a Control Flow Graph (Python/compile.c)\nEmit bytecode based on the Control Flow Graph (Python/compile.c)\n\nStarting with Python 2.5, the above steps are now used. This change\nwas done to simplify compilation by breaking it into three steps.\nThe purpose of this document is to outline how the latter three steps\nof the process works.\nThis document does not touch on how parsing works beyond what is needed\nto explain what is needed for compilation. It is also not exhaustive\nin terms of the how the entire system works. You will most likely need\nto read some source to have an exact understanding of all details.\n"}, | |
| {"id": "340", "title": "Anonymous Block Statements", "authors": "GvR", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "27-Apr-2005", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0340/", "abstract": "\nIntroduction\nThis PEP proposes a new type of compound statement which can be\nused for resource management purposes. The new statement type\nis provisionally called the block-statement because the keyword\nto be used has not yet been chosen.\nThis PEP competes with several other PEPs: PEP 288 (Generators\nAttributes and Exceptions; only the second part), PEP 310\n(Reliable Acquisition/Release Pairs), and PEP 325\n(Resource-Release Support for Generators).\nI should clarify that using a generator to \"drive\" a block\nstatement is really a separable proposal; with just the definition\nof the block statement from the PEP you could implement all the\nexamples using a class (similar to example 6, which is easily\nturned into a template). But the key idea is using a generator to\ndrive a block statement; the rest is elaboration, so I'd like to\nkeep these two parts together.\n(PEP 342, Enhanced Iterators, was originally a part of this PEP;\nbut the two proposals are really independent and with Steven\nBethard's help I have moved it to a separate PEP.)\n"}, | |
| {"id": "341", "title": "Unifying try-except and try-finally", "authors": "Brandl", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "04-May-2005", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0341/", "abstract": "\nAbstract\nThis PEP proposes a change in the syntax and semantics of try\nstatements to allow combined try-except-finally blocks. This\nmeans in short that it would be valid to write:\ntry:\n <do something>\nexcept Exception:\n <handle the error>\nfinally:\n <cleanup>\n\n\n"}, | |
| {"id": "342", "title": "Coroutines via Enhanced Generators", "authors": "GvR, Eby", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "10-May-2005", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0342/", "abstract": "\nIntroduction\nThis PEP proposes some enhancements to the API and syntax of generators, to\nmake them usable as simple coroutines. It is basically a combination of ideas\nfrom these two PEPs, which may be considered redundant if this PEP is\naccepted:\n\nPEP 288, Generators Attributes and Exceptions. The current PEP covers its\nsecond half, generator exceptions (in fact the throw() method name was\ntaken from PEP 288). PEP 342 replaces generator attributes, however, with a\nconcept from an earlier revision of PEP 288, the yield expression.\nPEP 325, Resource-Release Support for Generators. PEP 342 ties up a few\nloose ends in the PEP 325 spec, to make it suitable for actual\nimplementation.\n\n"}, | |
| {"id": "343", "title": "The \"with\" Statement", "authors": "GvR, Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "13-May-2005", "python_version": "2.5", "post_history": "02-Jun-2005, 16-Oct-2005, 29-Oct-2005, 23-Apr-2006, 01-May-2006, 30-Jul-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0343/", "abstract": "\nIntroduction\nAfter a lot of discussion about PEP 340 and alternatives, I\ndecided to withdraw PEP 340 and proposed a slight variant on PEP\n310. After more discussion, I have added back a mechanism for\nraising an exception in a suspended generator using a throw()\nmethod, and a close() method which throws a new GeneratorExit\nexception; these additions were first proposed on python-dev in\n[2] and universally approved of. I'm also changing the keyword to\n'with'.\nAfter acceptance of this PEP, the following PEPs were rejected due\nto overlap:\n\nPEP 310, Reliable Acquisition/Release Pairs. This is the\noriginal with-statement proposal.\nPEP 319, Python Synchronize/Asynchronize Block. Its use cases\ncan be covered by the current PEP by providing suitable\nwith-statement controllers: for 'synchronize' we can use the\n\"locking\" template from example 1; for 'asynchronize' we can use\na similar \"unlocking\" template. I don't think having an\n\"anonymous\" lock associated with a code block is all that\nimportant; in fact it may be better to always be explicit about\nthe mutex being used.\n\nPEP 340 and PEP 346 also overlapped with this PEP, but were\nvoluntarily withdrawn when this PEP was submitted.\nSome discussion of earlier incarnations of this PEP took place on\nthe Python Wiki [3].\n"}, | |
| {"id": "344", "title": "Exception Chaining and Embedded Tracebacks", "authors": "Yee", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "", "created": "12-May-2005", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0344/", "abstract": "\nAbstract\nThis PEP proposes three standard attributes on exception instances: the\n__context__ attribute for implicitly chained exceptions, the\n__cause__ attribute for explicitly chained exceptions, and the\n__traceback__ attribute for the traceback. A new raise ... from\nstatement sets the __cause__ attribute.\n"}, | |
| {"id": "345", "title": "Metadata for Python Software Packages 1.2", "authors": "Jones", "discussions_to": "distutils-sig@python.org", "status": "Superseded", "type": "Standards Track", "topic": "packaging", "created": "28-Apr-2005", "python_version": "2.7", "post_history": "`22-Dec-2009 <https://mail.python.org/archives/list/python-dev@python.org/thread/5QWS2FXKZNNPKNZO6RLPGT5NORS5ZQ2V/>`__", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/MKHXVV746H7ZDFN62Z72VNAX6KIRXNRO/", "requires": null, "replaces": "314", "superseded_by": "566", "url": "https://peps.python.org/pep-0345/", "abstract": "\nAbstract\nThis PEP describes a mechanism for adding metadata to Python distributions.\nIt includes specifics of the field names, and their semantics and\nusage.\nThis document specifies version 1.2 of the metadata format.\nVersion 1.0 is specified in PEP 241.\nVersion 1.1 is specified in PEP 314.\nVersion 1.2 of the metadata format adds a number of optional fields\ndesigned to make third-party packaging of Python Software easier.\nThese fields are \"Requires-Python\", \"Requires-External\", \"Requires-Dist\",\n\"Provides-Dist\", and \"Obsoletes-Dist\". This version also changes the\n\"Platform\" field. Three new fields were also added: \"Maintainer\",\n\"Maintainer-email\" and \"Project-URL\".\nLast, this new version also adds environment markers.\n"}, | |
| {"id": "346", "title": "User Defined (\"``with``\") Statements", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "06-May-2005", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0346/", "abstract": "\nIntroduction\nThis PEP proposes that Python's ability to reliably manage resources\nbe enhanced by the introduction of a new with statement that\nallows factoring out of arbitrary try/finally and some\ntry/except/else boilerplate. The new construct is called\na 'user defined statement', and the associated class definitions are\ncalled 'statement templates'.\nThe above is the main point of the PEP. However, if that was all it\nsaid, then PEP 310 would be sufficient and this PEP would be\nessentially redundant. Instead, this PEP recommends additional\nenhancements that make it natural to write these statement templates\nusing appropriately decorated generators. A side effect of those\nenhancements is that it becomes important to appropriately deal\nwith the management of resources inside generators.\nThis is quite similar to PEP 343, but the exceptions that occur are\nre-raised inside the generators frame, and the issue of generator\nfinalisation needs to be addressed as a result. The template\ngenerator decorator suggested by this PEP also creates reusable\ntemplates, rather than the single use templates of PEP 340.\nIn comparison to PEP 340, this PEP eliminates the ability to suppress\nexceptions, and makes the user defined statement a non-looping\nconstruct. The other main difference is the use of a decorator to\nturn generators into statement templates, and the incorporation of\nideas for addressing iterator finalisation.\nIf all that seems like an ambitious operation... well, Guido was the\none to set the bar that high when he wrote PEP 340 :)\n"}, | |
| {"id": "347", "title": "Migrating the Python CVS to Subversion", "authors": "von L\u00f6wis", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Process", "topic": "", "created": "14-Jul-2004", "python_version": null, "post_history": "14-Jul-2004", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0347/", "abstract": "\nAbstract\nThe Python source code is currently managed in a CVS repository on\nsourceforge.net. This PEP proposes to move it to a Subversion\nrepository on svn.python.org.\n"}, | |
| {"id": "348", "title": "Exception Reorganization for Python 3.0", "authors": "Cannon", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "28-Jul-2005", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0348/", "abstract": "\nAbstract\nPython, as of version 2.4, has 38 exceptions (including warnings) in\nthe built-in namespace in a rather shallow hierarchy. These\nclasses have come about over the years without a chance to learn from\nexperience. This PEP proposes doing a reorganization of the hierarchy\nfor Python 3.0 when backwards-compatibility is not as much of an\nissue.\nAlong with this reorganization, adding a requirement that all\nobjects passed to a raise statement must inherit from a specific\nsuperclass is proposed. This is to have guarantees about the basic\ninterface of exceptions and to further enhance the natural hierarchy\nof exceptions.\nLastly, bare except clauses will be changed to be semantically\nequivalent to except Exception. Most people currently use bare\nexcept clause for this purpose and with the exception hierarchy\nreorganization becomes a viable default.\n"}, | |
| {"id": "349", "title": "Allow str() to return unicode strings", "authors": "Schemenauer", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "02-Aug-2005", "python_version": "2.5", "post_history": "06-Aug-2005", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/M2Y3PUFLAE23NPRJPVBYF6P5LW5LVN6F/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0349/", "abstract": "\nAbstract\nThis PEP proposes to change the str() built-in function so that it\ncan return unicode strings. This change would make it easier to\nwrite code that works with either string type and would also make\nsome existing code handle unicode strings. The C function\nPyObject_Str() would remain unchanged and the function\nPyString_New() would be added instead.\n"}, | |
| {"id": "350", "title": "Codetags", "authors": "Elliott", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "27-Jun-2005", "python_version": null, "post_history": "10-Aug-2005, 26-Sep-2005", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0350/", "abstract": "\nAbstract\nThis informational PEP aims to provide guidelines for consistent use\nof codetags, which would enable the construction of standard\nutilities to take advantage of the codetag information, as well as\nmaking Python code more uniform across projects. Codetags also\nrepresent a very lightweight programming micro-paradigm and become\nuseful for project management, documentation, change tracking, and\nproject health monitoring. This is submitted as a PEP because its\nideas are thought to be Pythonic, although the concepts are not unique\nto Python programming. Herein are the definition of codetags, the\nphilosophy behind them, a motivation for standardized conventions,\nsome examples, a specification, a toolset description, and possible\nobjections to the Codetag project/paradigm.\nThis PEP is also living as a wiki for people to add comments.\n"}, | |
| {"id": "351", "title": "The freeze protocol", "authors": "Warsaw", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "14-Apr-2005", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0351/", "abstract": "\nAbstract\nThis PEP describes a simple protocol for requesting a frozen,\nimmutable copy of a mutable object. It also defines a new built-in\nfunction which uses this protocol to provide an immutable copy on any\ncooperating object.\n"}, | |
| {"id": "352", "title": "Required Superclass for Exceptions", "authors": "Cannon, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Oct-2005", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0352/", "abstract": "\nAbstract\nIn Python 2.4 and before, any (classic) class can be raised as an\nexception. The plan for 2.5 was to allow new-style classes, but this\nmakes the problem worse - it would mean any class (or\ninstance) can be raised! This is a problem as it prevents any\nguarantees from being made about the interface of exceptions.\nThis PEP proposes introducing a new superclass that all raised objects\nmust inherit from. Imposing the restriction will allow a standard\ninterface for exceptions to exist that can be relied upon. It also\nleads to a known hierarchy for all exceptions to adhere to.\nOne might counter that requiring a specific base class for a\nparticular interface is unPythonic. However, in the specific case of\nexceptions there's a good reason (which has generally been agreed to\non python-dev): requiring hierarchy helps code that wants to catch\nexceptions by making it possible to catch all exceptions explicitly\nby writing except BaseException: instead of\nexcept *:. [1]\nIntroducing a new superclass for exceptions also gives us the chance\nto rearrange the exception hierarchy slightly for the better. As it\ncurrently stands, all exceptions in the built-in namespace inherit\nfrom Exception. This is a problem since this includes two exceptions\n(KeyboardInterrupt and SystemExit) that often need to be excepted from\nthe application's exception handling: the default behavior of shutting\nthe interpreter down without a traceback is usually more desirable than\nwhatever the application might do (with the possible exception of\napplications that emulate Python's interactive command loop with\n>>> prompt). Changing it so that these two exceptions inherit\nfrom the common superclass instead of Exception will make it easy for\npeople to write except clauses that are not overreaching and not\ncatch exceptions that should propagate up.\nThis PEP is based on previous work done for PEP 348.\n"}, | |
| {"id": "353", "title": "Using ssize_t as the index type", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "18-Dec-2005", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0353/", "abstract": "\nAbstract\nIn Python 2.4, indices of sequences are restricted to the C type\nint. On 64-bit machines, sequences therefore cannot use the full\naddress space, and are restricted to 2**31 elements. This PEP proposes\nto change this, introducing a platform-specific index type\nPy_ssize_t. An implementation of the proposed change is in\nhttp://svn.python.org/projects/python/branches/ssize_t.\n"}, | |
| {"id": "354", "title": "Enumerations in Python", "authors": "Finney", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "", "created": "20-Dec-2005", "python_version": "2.6", "post_history": "20-Dec-2005", "resolution": null, "requires": null, "replaces": null, "superseded_by": "435", "url": "https://peps.python.org/pep-0354/", "abstract": "\nAbstract\nThis PEP specifies an enumeration data type for Python.\nAn enumeration is an exclusive set of symbolic names bound to\narbitrary unique values. Values within an enumeration can be iterated\nand compared, but the values have no inherent relationship to values\noutside the enumeration.\n"}, | |
| {"id": "355", "title": "Path - Object oriented filesystem paths", "authors": "Lindqvist", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "24-Jan-2006", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0355/", "abstract": "\nAbstract\nThis PEP describes a new class, Path, to be added to the os\nmodule, for handling paths in an object oriented fashion. The\n\"weak\" deprecation of various related functions is also discussed\nand recommended.\n"}, | |
| {"id": "356", "title": "Python 2.5 Release Schedule", "authors": "Norwitz, GvR, Baxter", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "07-Feb-2006", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0356/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 2.5. The schedule primarily concerns itself with PEP-sized\nitems. Small features may be added up to and including the first\nbeta release. Bugs may be fixed until the final release.\nThere will be at least two alpha releases, two beta releases, and\none release candidate. The release date is planned for\n12 September 2006.\n"}, | |
| {"id": "357", "title": "Allowing Any Object to be Used for Slicing", "authors": "Oliphant", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "09-Feb-2006", "python_version": "2.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0357/", "abstract": "\nAbstract\nThis PEP proposes adding an nb_index slot in PyNumberMethods and an\n__index__ special method so that arbitrary objects can be used\nwhenever integers are explicitly needed in Python, such as in slice\nsyntax (from which the slot gets its name).\n"}, | |
| {"id": "358", "title": "The \"bytes\" Object", "authors": "Schemenauer, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Feb-2006", "python_version": "2.6, 3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0358/", "abstract": "\nAbstract\nThis PEP outlines the introduction of a raw bytes sequence type.\nAdding the bytes type is one step in the transition to\nUnicode-based str objects which will be introduced in Python 3.0.\nThe PEP describes how the bytes type should work in Python 2.6, as\nwell as how it should work in Python 3.0. (Occasionally there are\ndifferences because in Python 2.6, we have two string types, str\nand unicode, while in Python 3.0 we will only have one string\ntype, whose name will be str but whose semantics will be like the\n2.6 unicode type.)\n"}, | |
| {"id": "359", "title": "The \"make\" Statement", "authors": "Bethard", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "05-Apr-2006", "python_version": "2.6", "post_history": "05-Apr-2006, 06-Apr-2006, 13-Apr-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0359/", "abstract": "\nAbstract\nThis PEP proposes a generalization of the class-declaration syntax,\nthe make statement. The proposed syntax and semantics parallel\nthe syntax for class definition, and so:\nmake <callable> <name> <tuple>:\n <block>\n\n\nis translated into the assignment:\n<name> = <callable>(\"<name>\", <tuple>, <namespace>)\n\n\nwhere <namespace> is the dict created by executing <block>.\nThis is mostly syntactic sugar for:\nclass <name> <tuple>:\n __metaclass__ = <callable>\n <block>\n\n\nand is intended to help more clearly express the intent of the\nstatement when something other than a class is being created. Of\ncourse, other syntax for such a statement is possible, but it is hoped\nthat by keeping a strong parallel to the class statement, an\nunderstanding of how classes and metaclasses work will translate into\nan understanding of how the make-statement works as well.\nThe PEP is based on a suggestion [1] from Michele Simionato on the\npython-dev list.\n"}, | |
| {"id": "360", "title": "Externally Maintained Packages", "authors": "Cannon", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "30-May-2006", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0360/", "abstract": "\nAbstract\nThere are many great pieces of Python software developed outside of\nthe Python standard library (a.k.a., the \"stdlib\"). Sometimes it\nmakes sense to incorporate these externally maintained packages into\nthe stdlib in order to fill a gap in the tools provided by Python.\nBut by having the packages maintained externally it means Python's\ndevelopers do not have direct control over the packages' evolution and\nmaintenance. Some package developers prefer to have bug reports and\npatches go through them first instead of being directly applied to\nPython's repository.\nThis PEP is meant to record details of packages in the stdlib that are\nmaintained outside of Python's repository. Specifically, it is meant\nto keep track of any specific maintenance needs for each package. It\nshould be mentioned that changes needed in order to fix bugs and keep\nthe code running on all of Python's supported platforms will be done\ndirectly in Python's repository without worrying about going through\nthe contact developer. This is so that Python itself is not held up\nby a single bug and allows the whole process to scale as needed.\nIt also is meant to allow people to know which version of a package is\nreleased with which version of Python.\n"}, | |
| {"id": "361", "title": "Python 2.6 and 3.0 Release Schedule", "authors": "Norwitz, Warsaw", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "29-Jun-2006", "python_version": "2.6, 3.0", "post_history": "17-Mar-2008", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0361/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 2.6 and 3.0. The schedule primarily concerns itself with\nPEP-sized items. Small features may be added up to and including\nthe first beta release. Bugs may be fixed until the final\nrelease.\nThere will be at least two alpha releases, two beta releases, and\none release candidate. The releases are planned for October 2008.\nPython 2.6 is not only the next advancement in the Python 2\nseries, it is also a transitional release, helping developers\nbegin to prepare their code for Python 3.0. As such, many\nfeatures are being backported from Python 3.0 to 2.6. Thus, it\nmakes sense to release both versions in at the same time. The\nprecedence for this was set with the Python 1.6 and 2.0 release.\nUntil rc, we will be releasing Python 2.6 and 3.0 in lockstep, on\na monthly release cycle. The releases will happen on the first\nWednesday of every month through the beta testing cycle. Because\nPython 2.6 is ready sooner, and because we have outside deadlines\nwe'd like to meet, we've decided to split the rc releases. Thus\nPython 2.6 final is currently planned to come out two weeks before\nPython 3.0 final.\n"}, | |
| {"id": "362", "title": "Function Signature Object", "authors": "Cannon, Seo, Selivanov, Hastings", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "21-Aug-2006", "python_version": "3.3", "post_history": "04-Jun-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-June/120682.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0362/", "abstract": "\nAbstract\nPython has always supported powerful introspection capabilities,\nincluding introspecting functions and methods (for the rest of\nthis PEP, \"function\" refers to both functions and methods). By\nexamining a function object you can fully reconstruct the function's\nsignature. Unfortunately this information is stored in an inconvenient\nmanner, and is spread across a half-dozen deeply nested attributes.\nThis PEP proposes a new representation for function signatures.\nThe new representation contains all necessary information about a function\nand its parameters, and makes introspection easy and straightforward.\nHowever, this object does not replace the existing function\nmetadata, which is used by Python itself to execute those\nfunctions. The new metadata object is intended solely to make\nfunction introspection easier for Python programmers.\n"}, | |
| {"id": "363", "title": "Syntax For Dynamic Attribute Access", "authors": "North", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "29-Jan-2007", "python_version": null, "post_history": "12-Feb-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0363/", "abstract": "\nAbstract\nDynamic attribute access is currently possible using the \"getattr\"\nand \"setattr\" builtins. The present PEP suggests a new syntax to\nmake such access easier, allowing the coder for example to write:\nx.('foo_%d' % n) += 1\n\nz = y.('foo_%d' % n).('bar_%s' % s)\n\n\ninstead of:\nattr_name = 'foo_%d' % n\nsetattr(x, attr_name, getattr(x, attr_name) + 1)\n\nz = getattr(getattr(y, 'foo_%d' % n), 'bar_%s' % s)\n\n\n"}, | |
| {"id": "364", "title": "Transitioning to the Py3K Standard Library", "authors": "Warsaw", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "01-Mar-2007", "python_version": "2.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0364/", "abstract": "\nAbstract\nPEP 3108 describes the reorganization of the Python standard library\nfor the Python 3.0 release. This PEP describes a\nmechanism for transitioning from the Python 2.x standard library to\nthe Python 3.0 standard library. This transition will allow and\nencourage Python programmers to use the new Python 3.0 library names\nstarting with Python 2.6, while maintaining the old names for backward\ncompatibility. In this way, a Python programmer will be able to write\nforward compatible code without sacrificing interoperability with\nexisting Python programs.\n"}, | |
| {"id": "365", "title": "Adding the pkg_resources module", "authors": "Eby", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "30-Apr-2007", "python_version": null, "post_history": "30-Apr-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0365/", "abstract": "\nAbstract\nThis PEP proposes adding an enhanced version of the pkg_resources\nmodule to the standard library.\npkg_resources is a module used to find and manage Python\npackage/version dependencies and access bundled files and resources,\nincluding those inside of zipped .egg files. Currently,\npkg_resources is only available through installing the entire\nsetuptools distribution, but it does not depend on any other part\nof setuptools; in effect, it comprises the entire runtime support\nlibrary for Python Eggs, and is independently useful.\nIn addition, with one feature addition, this module could support\neasy bootstrap installation of several Python package management\ntools, including setuptools, workingenv, and zc.buildout.\n"}, | |
| {"id": "366", "title": "Main module explicit relative imports", "authors": "Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-May-2007", "python_version": "2.6, 3.0", "post_history": "01-May-2007, 04-Jul-2007, 07-Jul-2007, 23-Nov-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0366/", "abstract": "\nAbstract\nThis PEP proposes a backwards compatible mechanism that permits\nthe use of explicit relative imports from executable modules within\npackages. Such imports currently fail due to an awkward interaction\nbetween PEP 328 and PEP 338.\nBy adding a new module level attribute, this PEP allows relative imports\nto work automatically if the module is executed using the -m switch.\nA small amount of boilerplate in the module itself will allow the relative\nimports to work when the file is executed by name.\nGuido accepted the PEP in November 2007 [5].\n"}, | |
| {"id": "367", "title": "New Super", "authors": "Spealman, Delaney", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "", "created": "28-Apr-2007", "python_version": "2.6", "post_history": "`28-Apr-2007 <https://mail.python.org/pipermail/python-dev/2007-April/072807.html>`__, `29-Apr-2007 <https://mail.python.org/pipermail/python-dev/2007-April/072835.html>`__, `29-Apr-2007 <https://mail.python.org/pipermail/python-dev/2007-April/072858.html>`__, `14-May-2007 <https://mail.python.org/pipermail/python-dev/2007-May/073127.html>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0367/", "abstract": "\nAbstract\nThis PEP proposes syntactic sugar for use of the super type to automatically\nconstruct instances of the super type binding to the class that a method was\ndefined in, and the instance (or class object for classmethods) that the method\nis currently acting upon.\nThe premise of the new super usage suggested is as follows:\nsuper.foo(1, 2)\n\n\nto replace the old:\nsuper(Foo, self).foo(1, 2)\n\n\nand the current __builtin__.super be aliased to __builtin__.__super__\n(with __builtin__.super to be removed in Python 3.0).\nIt is further proposed that assignment to super become a SyntaxError,\nsimilar to the behaviour of None.\n"}, | |
| {"id": "368", "title": "Standard image protocol and class", "authors": "Mastrodomenico", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "28-Jun-2007", "python_version": "2.6, 3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0368/", "abstract": "\nAbstract\nThe current situation of image storage and manipulation in the Python\nworld is extremely fragmented: almost every library that uses image\nobjects has implemented its own image class, incompatible with\neveryone else's and often not very pythonic. A basic RGB image class\nexists in the standard library (Tkinter.PhotoImage), but is pretty\nmuch unusable, and unused, for anything except Tkinter programming.\nThis fragmentation not only takes up valuable space in the developers\nminds, but also makes the exchange of images between different\nlibraries (needed in relatively common use cases) slower and more\ncomplex than it needs to be.\nThis PEP proposes to improve the situation by defining a simple and\npythonic image protocol/interface that can be hopefully accepted and\nimplemented by existing image classes inside and outside the standard\nlibrary without breaking backward compatibility with their existing\nuser bases. In practice this is a definition of how a minimal\nimage-like object should look and act (in a similar way to the\nread() and write() methods in file-like objects).\nThe inclusion in the standard library of a class that provides basic\nimage manipulation functionality and implements the new protocol is\nalso proposed, together with a mixin class that helps adding support\nfor the protocol to existing image classes.\n"}, | |
| {"id": "369", "title": "Post import hooks", "authors": "Heimes", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "02-Jan-2008", "python_version": "2.6, 3.0", "post_history": "02-Dec-2012", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0369/", "abstract": "\nAbstract\nThis PEP proposes enhancements for the import machinery to add\npost import hooks. It is intended primarily to support the wider\nuse of abstract base classes that is expected in Python 3.0.\nThe PEP originally started as a combined PEP for lazy imports and\npost import hooks. After some discussion on the python-dev mailing\nlist the PEP was parted in two separate PEPs. [1]\n"}, | |
| {"id": "370", "title": "Per user site-packages directory", "authors": "Heimes", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "11-Jan-2008", "python_version": "2.6, 3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0370/", "abstract": "\nAbstract\nThis PEP proposes a new a per user site-packages directory to allow\nusers the local installation of Python packages in their home directory.\n"}, | |
| {"id": "371", "title": "Addition of the multiprocessing package to the standard library", "authors": "Noller, Oudkerk", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "06-May-2008", "python_version": "2.6, 3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0371/", "abstract": "\nAbstract\nThis PEP proposes the inclusion of the pyProcessing [1] package\ninto the Python standard library, renamed to \"multiprocessing\".\nThe processing package mimics the standard library threading\nmodule functionality to provide a process-based approach to\nthreaded programming allowing end-users to dispatch multiple\ntasks that effectively side-step the global interpreter lock.\nThe package also provides server and client functionality\n(processing.Manager) to provide remote sharing and management of\nobjects and tasks so that applications may not only leverage\nmultiple cores on the local machine, but also distribute objects\nand tasks across a cluster of networked machines.\nWhile the distributed capabilities of the package are beneficial,\nthe primary focus of this PEP is the core threading-like API and\ncapabilities of the package.\n"}, | |
| {"id": "372", "title": "Adding an ordered dictionary to collections", "authors": "Ronacher, Hettinger", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Jun-2008", "python_version": "2.7, 3.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0372/", "abstract": "\nAbstract\nThis PEP proposes an ordered dictionary as a new data structure for\nthe collections module, called \"OrderedDict\" in this PEP. The\nproposed API incorporates the experiences gained from working with\nsimilar implementations that exist in various real-world applications\nand other programming languages.\n"}, | |
| {"id": "373", "title": "Python 2.7 Release Schedule", "authors": "Peterson", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "03-Nov-2008", "python_version": "2.7", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0373/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 2.7.\nPython 2.7 is the end of the Python 2.x series, and is succeeded by\nPython 3. See the \"Sunsetting Python 2\" FAQ on python.org for a general\noverview.\n"}, | |
| {"id": "374", "title": "Choosing a distributed VCS for the Python project", "authors": "Cannon, Turnbull, Vassalotti, Warsaw, Ochtman", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "07-Nov-2008", "python_version": null, "post_history": "07-Nov-2008, 22-Jan-2009", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0374/", "abstract": ""}, | |
| {"id": "375", "title": "Python 3.1 Release Schedule", "authors": "Peterson", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "08-Feb-2009", "python_version": "3.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0375/", "abstract": "\nAbstract\nThis document describes the development and release schedule for Python 3.1.\nThe schedule primarily concerns itself with PEP-sized items. Small features may\nbe added up to and including the first beta release. Bugs may be fixed until\nthe final release.\n"}, | |
| {"id": "376", "title": "Database of Installed Python Distributions", "authors": "Ziad\u00e9", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "22-Feb-2009", "python_version": "2.7, 3.2", "post_history": "`22-Jun-2009 <https://mail.python.org/archives/list/python-dev@python.org/thread/ILLTIOZAULMDY5CAS6GOITEYJ4HNFATQ/#ILLTIOZAULMDY5CAS6GOITEYJ4HNFATQ>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0376/", "abstract": "\nAbstract\nThe goal of this PEP is to provide a standard infrastructure to manage\nproject distributions installed on a system, so all tools that are\ninstalling or removing projects are interoperable.\nTo achieve this goal, the PEP proposes a new format to describe installed\ndistributions on a system. It also describes a reference implementation\nfor the standard library.\nIn the past an attempt was made to create an installation database\n(see PEP 262).\nCombined with PEP 345, the current proposal supersedes PEP 262.\nNote: the implementation plan didn't go as expected, so it should be\nconsidered informative only for this PEP.\n"}, | |
| {"id": "377", "title": "Allow __enter__() methods to skip the statement body", "authors": "Coghlan", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "08-Mar-2009", "python_version": "2.7, 3.1", "post_history": "08-Mar-2009", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0377/", "abstract": "\nAbstract\nThis PEP proposes a backwards compatible mechanism that allows __enter__()\nmethods to skip the body of the associated with statement. The lack of\nthis ability currently means the contextlib.contextmanager decorator\nis unable to fulfil its specification of being able to turn arbitrary\ncode into a context manager by moving it into a generator function\nwith a yield in the appropriate location. One symptom of this is that\ncontextlib.nested will currently raise RuntimeError in\nsituations where writing out the corresponding nested with\nstatements would not [1].\nThe proposed change is to introduce a new flow control exception\nSkipStatement, and skip the execution of the with\nstatement body if __enter__() raises this exception.\n"}, | |
| {"id": "378", "title": "Format Specifier for Thousands Separator", "authors": "Hettinger", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "12-Mar-2009", "python_version": "2.7, 3.1", "post_history": "12-Mar-2009", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0378/", "abstract": ""}, | |
| {"id": "379", "title": "Adding an Assignment Expression", "authors": "Whitley", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "14-Mar-2009", "python_version": "2.7, 3.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0379/", "abstract": "\nAbstract\nThis PEP adds a new assignment expression to the Python language\nto make it possible to assign the result of an expression in\nalmost any place. The new expression will allow the assignment of\nthe result of an expression at first use (in a comparison for\nexample).\n"}, | |
| {"id": "380", "title": "Syntax for Delegating to a Subgenerator", "authors": "Ewing", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "13-Feb-2009", "python_version": "3.3", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2011-June/112010.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0380/", "abstract": "\nAbstract\nA syntax is proposed for a generator to delegate part of its\noperations to another generator. This allows a section of code\ncontaining 'yield' to be factored out and placed in another generator.\nAdditionally, the subgenerator is allowed to return with a value, and\nthe value is made available to the delegating generator.\nThe new syntax also opens up some opportunities for optimisation when\none generator re-yields values produced by another.\n"}, | |
| {"id": "381", "title": "Mirroring infrastructure for PyPI", "authors": "Ziad\u00e9, von L\u00f6wis", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "packaging", "created": "21-Mar-2009", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0381/", "abstract": "\nAbstract\nThis PEP describes a mirroring infrastructure for PyPI.\n"}, | |
| {"id": "382", "title": "Namespace Packages", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "02-Apr-2009", "python_version": "3.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0382/", "abstract": "\nAbstract\nNamespace packages are a mechanism for splitting a single Python\npackage across multiple directories on disk. In current Python\nversions, an algorithm to compute the packages __path__ must be\nformulated. With the enhancement proposed here, the import machinery\nitself will construct the list of directories that make up the\npackage. An implementation of this PEP is available at [1].\n"}, | |
| {"id": "383", "title": "Non-decodable Bytes in System Character Interfaces", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "22-Apr-2009", "python_version": "3.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0383/", "abstract": "\nAbstract\nFile names, environment variables, and command line arguments are\ndefined as being character data in POSIX; the C APIs however allow\npassing arbitrary bytes - whether these conform to a certain encoding\nor not. This PEP proposes a means of dealing with such irregularities\nby embedding the bytes in character strings in such a way that allows\nrecreation of the original byte string.\n"}, | |
| {"id": "384", "title": "Defining a Stable ABI", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "17-May-2009", "python_version": "3.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0384/", "abstract": "\nAbstract\nCurrently, each feature release introduces a new name for the\nPython DLL on Windows, and may cause incompatibilities for extension\nmodules on Unix. This PEP proposes to define a stable set of API\nfunctions which are guaranteed to be available for the lifetime\nof Python 3, and which will also remain binary-compatible across\nversions. Extension modules and applications embedding Python\ncan work with different feature releases as long as they restrict\nthemselves to this stable ABI.\n"}, | |
| {"id": "385", "title": "Migrating from Subversion to Mercurial", "authors": "Ochtman, Pitrou, Brandl", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "25-May-2009", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0385/", "abstract": ""}, | |
| {"id": "386", "title": "Changing the version comparison module in Distutils", "authors": "Ziad\u00e9", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "packaging", "created": "04-Jun-2009", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": "440", "url": "https://peps.python.org/pep-0386/", "abstract": "\nAbstract\nNote: This PEP has been superseded by the version identification and\ndependency specification scheme defined in PEP 440.\nThis PEP proposed a new version comparison schema system in Distutils.\n"}, | |
| {"id": "387", "title": "Backwards Compatibility Policy", "authors": "Peterson", "discussions_to": "https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421", "status": "Active", "type": "Process", "topic": "", "created": "18-Jun-2009", "python_version": null, "post_history": "19-Jun-2009, 12-Jun-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0387/", "abstract": "\nAbstract\nThis PEP outlines Python's backwards compatibility policy.\n"}, | |
| {"id": "389", "title": "argparse - New Command Line Parsing Module", "authors": "Bethard", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "25-Sep-2009", "python_version": "2.7, 3.2", "post_history": "27-Sep-2009, 24-Oct-2009", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0389/", "abstract": "\nAbstract\nThis PEP proposes inclusion of the argparse [1] module in the Python\nstandard library in Python 2.7 and 3.2.\n"}, | |
| {"id": "390", "title": "Static metadata for Distutils", "authors": "Ziad\u00e9", "discussions_to": "distutils-sig@python.org", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "10-Oct-2009", "python_version": "2.7, 3.2", "post_history": null, "resolution": "https://mail.python.org/pipermail/distutils-sig/2013-April/020597.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0390/", "abstract": "\nAbstract\nThis PEP describes a new section and a new format for the setup.cfg file,\nthat allows describing the Metadata of a package without using setup.py.\n"}, | |
| {"id": "391", "title": "Dictionary-Based Configuration For Logging", "authors": "Sajip", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Oct-2009", "python_version": "2.7, 3.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0391/", "abstract": "\nAbstract\nThis PEP describes a new way of configuring logging using a dictionary\nto hold configuration information.\n"}, | |
| {"id": "392", "title": "Python 3.2 Release Schedule", "authors": "Brandl", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "30-Dec-2009", "python_version": "3.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0392/", "abstract": "\nAbstract\nThis document describes the development and release schedule for the\nPython 3.2 series. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "393", "title": "Flexible String Representation", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "24-Jan-2010", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0393/", "abstract": "\nAbstract\nThe Unicode string type is changed to support multiple internal\nrepresentations, depending on the character with the largest Unicode\nordinal (1, 2, or 4 bytes). This will allow a space-efficient\nrepresentation in common cases, but give access to full UCS-4 on all\nsystems. For compatibility with existing APIs, several representations\nmay exist in parallel; over time, this compatibility should be phased\nout. The distinction between narrow and wide Unicode builds is\ndropped. An implementation of this PEP is available at [1].\n"}, | |
| {"id": "394", "title": "The \"python\" Command on Unix-Like Systems", "authors": "Staley, Coghlan, Warsaw, Viktorin, Hron\u010dok, Willing", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "02-Mar-2011", "python_version": null, "post_history": "04-Mar-2011, 20-Jul-2011, 16-Feb-2012, 30-Sep-2014, 28-Apr-2018, 26-Jun-2019", "resolution": "https://mail.python.org/pipermail/python-dev/2012-February/116594.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0394/", "abstract": "\nAbstract\nThis PEP outlines the behavior of Python scripts when the python command\nis invoked.\nDepending on a distribution or system configuration,\npython may or may not be installed.\nIf python is installed its target interpreter may refer to python2\nor python3.\nEnd users may be unaware of this inconsistency across Unix-like systems.\nThis PEP's goal is to reduce user confusion about what python references\nand what will be the script's behavior.\nThe recommendations in the next section of this PEP will outline the behavior\nwhen:\n\nusing virtual environments\nwriting cross-platform scripts with shebangs for either python2 or python3\n\nThe PEP's goal is to clarify the behavior for script end users, distribution\nproviders, and script maintainers / authors.\n"}, | |
| {"id": "395", "title": "Qualified Names for Modules", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "04-Mar-2011", "python_version": "3.4", "post_history": "05-Mar-2011, 19-Nov-2011", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0395/", "abstract": "\nAbstract\nThis PEP proposes new mechanisms that eliminate some longstanding traps for\nthe unwary when dealing with Python's import system, as well as serialisation\nand introspection of functions and classes.\nIt builds on the \"Qualified Name\" concept defined in PEP 3155.\n\nRelationship with Other PEPs\nMost significantly, this PEP is currently deferred as it requires\nsignificant changes in order to be made compatible with the removal\nof mandatory __init__.py files in PEP 420 (which has been implemented\nand released in Python 3.3).\nThis PEP builds on the \"qualified name\" concept introduced by PEP 3155, and\nalso shares in that PEP's aim of fixing some ugly corner cases when dealing\nwith serialisation of arbitrary functions and classes.\nIt also builds on PEP 366, which took initial tentative steps towards making\nexplicit relative imports from the main module work correctly in at least\nsome circumstances.\nFinally, PEP 328 eliminated implicit relative imports from imported modules.\nThis PEP proposes that the de facto implicit relative imports from main\nmodules that are provided by the current initialisation behaviour for\nsys.path[0] also be eliminated.\n\n"}, | |
| {"id": "396", "title": "Module Version Numbers", "authors": "Warsaw", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "packaging", "created": "16-Mar-2011", "python_version": null, "post_history": "05-Apr-2011", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0396/", "abstract": "\nAbstract\nGiven that it is useful and common to specify version numbers for\nPython modules, and given that different ways of doing this have grown\norganically within the Python community, it is useful to establish\nstandard conventions for module authors to adhere to and reference.\nThis informational PEP describes best practices for Python module\nauthors who want to define the version number of their Python module.\nConformance with this PEP is optional, however other Python tools\n(such as distutils2 [1]) may be adapted to use the conventions\ndefined here.\n"}, | |
| {"id": "397", "title": "Python launcher for Windows", "authors": "Hammond, von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Mar-2011", "python_version": "3.3", "post_history": "21-Jul-2011, 17-May-2011, 15-Mar-2011", "resolution": "https://mail.python.org/pipermail/python-dev/2012-June/120505.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0397/", "abstract": "\nAbstract\nThis PEP describes a Python launcher for the Windows platform. A\nPython launcher is a single executable which uses a number of\nheuristics to locate a Python executable and launch it with a\nspecified command line.\n"}, | |
| {"id": "398", "title": "Python 3.3 Release Schedule", "authors": "Brandl", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "23-Mar-2011", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0398/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.3. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "399", "title": "Pure Python/C Accelerator Module Compatibility Requirements", "authors": "Cannon", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "04-Apr-2011", "python_version": "3.3", "post_history": "04-Apr-2011, 12-Apr-2011, 17-Jul-2011, 15-Aug-2011, 01-Jan-2013", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0399/", "abstract": "\nAbstract\nThe Python standard library under CPython contains various instances\nof modules implemented in both pure Python and C (either entirely or\npartially). This PEP requires that in these instances that the\nC code must pass the test suite used for the pure Python code\nso as to act as much as a drop-in replacement as reasonably possible\n(C- and VM-specific tests are exempt). It is also required that new\nC-based modules lacking a pure Python equivalent implementation get\nspecial permission to be added to the standard library.\n"}, | |
| {"id": "400", "title": "Deprecate codecs.StreamReader and codecs.StreamWriter", "authors": "Stinner", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "28-May-2011", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0400/", "abstract": "\nAbstract\nio.TextIOWrapper and codecs.StreamReaderWriter offer the same API\n[1]. TextIOWrapper has more features and is faster than\nStreamReaderWriter. Duplicate code means that bugs should be fixed\ntwice and that we may have subtle differences between the two\nimplementations.\nThe codecs module was introduced in Python 2.0 (see the PEP 100).\nThe io module was\nintroduced in Python 2.6 and 3.0 (see the PEP 3116),\nand reimplemented in C in\nPython 2.7 and 3.1.\n"}, | |
| {"id": "401", "title": "BDFL Retirement", "authors": "Warsaw, Cannon", "discussions_to": null, "status": "Rejected", "type": "Process", "topic": "", "created": "01-Apr-2009", "python_version": null, "post_history": "01-Apr-2009", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0401/", "abstract": "\nAbstract\nThe BDFL, having shepherded Python development for 20 years,\nofficially announces his retirement, effective immediately. Following\na unanimous vote, his replacement is named.\n"}, | |
| {"id": "402", "title": "Simplified Package Layout and Partitioning", "authors": "Eby", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "12-Jul-2011", "python_version": "3.3", "post_history": "20-Jul-2011", "resolution": null, "requires": null, "replaces": "382", "superseded_by": null, "url": "https://peps.python.org/pep-0402/", "abstract": "\nAbstract\nThis PEP proposes an enhancement to Python's package importing\nto:\n\nSurprise users of other languages less,\nMake it easier to convert a module into a package, and\nSupport dividing packages into separately installed components\n(ala \"namespace packages\", as described in PEP 382)\n\nThe proposed enhancements do not change the semantics of any\ncurrently-importable directory layouts, but make it possible for\npackages to use a simplified directory layout (that is not importable\ncurrently).\nHowever, the proposed changes do NOT add any performance overhead to\nthe importing of existing modules or packages, and performance for the\nnew directory layout should be about the same as that of previous\n\"namespace package\" solutions (such as pkgutil.extend_path()).\n"}, | |
| {"id": "403", "title": "General purpose decorator clause (aka \"@in\" clause)", "authors": "Coghlan", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "13-Oct-2011", "python_version": "3.4", "post_history": "13-Oct-2011", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0403/", "abstract": "\nAbstract\nThis PEP proposes the addition of a new @in decorator clause that makes\nit possible to override the name binding step of a function or class\ndefinition.\nThe new clause accepts a single simple statement that can make a forward\nreference to decorated function or class definition.\nThis new clause is designed to be used whenever a \"one-shot\" function or\nclass is needed, and placing the function or class definition before the\nstatement that uses it actually makes the code harder to read. It also\navoids any name shadowing concerns by making sure the new name is visible\nonly to the statement in the @in clause.\nThis PEP is based heavily on many of the ideas in PEP 3150 (Statement Local\nNamespaces) so some elements of the rationale will be familiar to readers of\nthat PEP. Both PEPs remain deferred for the time being, primarily due to the\nlack of compelling real world use cases in either PEP.\n"}, | |
| {"id": "404", "title": "Python 2.8 Un-release Schedule", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "09-Nov-2011", "python_version": "2.8", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0404/", "abstract": "\nAbstract\nThis document describes the un-development and un-release schedule for Python\n2.8.\n"}, | |
| {"id": "405", "title": "Python Virtual Environments", "authors": "Meyer", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "13-Jun-2011", "python_version": "3.3", "post_history": "24-Oct-2011, 28-Oct-2011, 06-Mar-2012, 24-May-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-May/119668.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0405/", "abstract": "\nAbstract\nThis PEP proposes to add to Python a mechanism for lightweight\n\"virtual environments\" with their own site directories, optionally\nisolated from system site directories. Each virtual environment has\nits own Python binary (allowing creation of environments with various\nPython versions) and can have its own independent set of installed\nPython packages in its site directories, but shares the standard\nlibrary with the base installed Python.\n"}, | |
| {"id": "406", "title": "Improved Encapsulation of Import State", "authors": "Coghlan, Slodkowicz", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "04-Jul-2011", "python_version": "3.4", "post_history": "31-Jul-2011, 13-Nov-2011, 04-Dec-2011", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0406/", "abstract": "\nAbstract\nThis PEP proposes the introduction of a new 'ImportEngine' class as part of\nimportlib which would encapsulate all state related to importing modules\ninto a single object. Creating new instances of this object would then provide\nan alternative to completely replacing the built-in implementation of the\nimport statement, by overriding the __import__() function. To work with\nthe builtin import functionality and importing via import engine objects,\nthis PEP proposes a context management based approach to temporarily replacing\nthe global import state.\nThe PEP also proposes inclusion of a GlobalImportEngine subclass and a\nglobally accessible instance of that class, which \"writes through\" to the\nprocess global state. This provides a backwards compatible bridge between the\nproposed encapsulated API and the legacy process global state, and allows\nstraightforward support for related state updates (e.g. selectively\ninvalidating path cache entries when sys.path is modified).\n"}, | |
| {"id": "407", "title": "New release cycle and introducing long-term support versions", "authors": "Pitrou, Brandl, Warsaw", "discussions_to": null, "status": "Deferred", "type": "Process", "topic": "", "created": "12-Jan-2012", "python_version": null, "post_history": "17-Jan-2012", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0407/", "abstract": "\nAbstract\nFinding a release cycle for an open-source project is a delicate\nexercise in managing mutually contradicting constraints: developer\nmanpower, availability of release management volunteers, ease of\nmaintenance for users and third-party packagers, quick availability of\nnew features (and behavioural changes), availability of bug fixes\nwithout pulling in new features or behavioural changes.\nThe current release cycle errs on the conservative side. It is\nadequate for people who value stability over reactivity. This PEP is\nan attempt to keep the stability that has become a Python trademark,\nwhile offering a more fluid release of features, by introducing the\nnotion of long-term support versions.\n"}, | |
| {"id": "408", "title": "Standard library __preview__ package", "authors": "Coghlan, Bendersky", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "07-Jan-2012", "python_version": "3.3", "post_history": "27-Jan-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-January/115962.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0408/", "abstract": "\nAbstract\nThe process of including a new module into the Python standard library is\nhindered by the API lock-in and promise of backward compatibility implied by\na module being formally part of Python. This PEP proposes a transitional\nstate for modules - inclusion in a special __preview__ package for the\nduration of a minor release (roughly 18 months) prior to full acceptance into\nthe standard library. On one hand, this state provides the module with the\nbenefits of being formally part of the Python distribution. On the other hand,\nthe core development team explicitly states that no promises are made with\nregards to the module's eventual full inclusion into the standard library,\nor to the stability of its API, which may change for the next release.\n"}, | |
| {"id": "409", "title": "Suppressing exception context", "authors": "Furman", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Jan-2012", "python_version": "3.3", "post_history": "30-Aug-2002, 01-Feb-2012, 03-Feb-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-February/116136.html", "requires": null, "replaces": null, "superseded_by": "415", "url": "https://peps.python.org/pep-0409/", "abstract": "\nAbstract\nOne of the open issues from PEP 3134 is suppressing context: currently\nthere is no way to do it. This PEP proposes one.\n"}, | |
| {"id": "410", "title": "Use decimal.Decimal type for timestamps", "authors": "Stinner", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "01-Feb-2012", "python_version": "3.3", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2012-February/116837.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0410/", "abstract": "\nAbstract\nDecimal becomes the official type for high-resolution timestamps to make Python\nsupport new functions using a nanosecond resolution without loss of precision.\n"}, | |
| {"id": "411", "title": "Provisional packages in the Python standard library", "authors": "Coghlan, Bendersky", "discussions_to": null, "status": "Superseded", "type": "Informational", "topic": "", "created": "10-Feb-2012", "python_version": "3.3", "post_history": "10-Feb-2012, 24-Mar-2012", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0411/", "abstract": "\nAbstract\nThe process of including a new package into the Python standard library is\nhindered by the API lock-in and promise of backward compatibility implied by\na package being formally part of Python. This PEP describes a methodology\nfor marking a standard library package \"provisional\" for the period of a single\nfeature release. A provisional package may have its API modified prior to\n\"graduating\" into a \"stable\" state. On one hand, this state provides the\npackage with the benefits of being formally part of the Python distribution.\nOn the other hand, the core development team explicitly states that no promises\nare made with regards to the stability of the package's API, which may\nchange for the next release. While it is considered an unlikely outcome,\nsuch packages may even be removed from the standard library without a\ndeprecation period if the concerns regarding their API or maintenance prove\nwell-founded.\n"}, | |
| {"id": "412", "title": "Key-Sharing Dictionary", "authors": "Shannon", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "08-Feb-2012", "python_version": "3.3", "post_history": "08-Feb-2012", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0412/", "abstract": "\nAbstract\nThis PEP proposes a change in the implementation of the builtin\ndictionary type dict. The new implementation allows dictionaries\nwhich are used as attribute dictionaries (the __dict__ attribute\nof an object) to share keys with other attribute dictionaries of\ninstances of the same class.\n"}, | |
| {"id": "413", "title": "Faster evolution of the Python Standard Library", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "24-Feb-2012", "python_version": null, "post_history": "24-Feb-2012, 25-Feb-2012", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0413/", "abstract": "\nAbstract\nThis PEP proposes the adoption of a separate versioning scheme for the\nstandard library (distinct from, but coupled to, the existing language\nversioning scheme) that allows accelerated releases of the Python standard\nlibrary, while maintaining (or even slowing down) the current rate of\nchange in the core language definition.\nLike PEP 407, it aims to adjust the current balance between measured\nchange that allows the broader community time to adapt and being able to\nkeep pace with external influences that evolve more rapidly than the current\nrelease cycle can handle (this problem is particularly notable for\nstandard library elements that relate to web technologies).\nHowever, it's more conservative in its aims than PEP 407, seeking to\nrestrict the increased pace of development to builtin and standard library\ninterfaces, without affecting the rate of change for other elements such\nas the language syntax and version numbering as well as the CPython\nbinary API and bytecode format.\n"}, | |
| {"id": "414", "title": "Explicit Unicode Literal for Python 3.3", "authors": "Ronacher, Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Feb-2012", "python_version": "3.3", "post_history": "28-Feb-2012, 04-Mar-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-February/116995.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0414/", "abstract": "\nAbstract\nThis document proposes the reintegration of an explicit unicode literal\nfrom Python 2.x to the Python 3.x language specification, in order to\nreduce the volume of changes needed when porting Unicode-aware\nPython 2 applications to Python 3.\n"}, | |
| {"id": "415", "title": "Implement context suppression with exception attributes", "authors": "Peterson", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Feb-2012", "python_version": "3.3", "post_history": "26-Feb-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-May/119467.html", "requires": null, "replaces": "409", "superseded_by": null, "url": "https://peps.python.org/pep-0415/", "abstract": "\nAbstract\nPEP 409 introduced support for the raise exc from None construct to\nallow the display of the exception context to be explicitly suppressed.\nThis PEP retains the language level changes already implemented in PEP 409,\nbut replaces the underlying implementation mechanism with a simpler approach\nbased on a new __suppress_context__ attribute on all BaseException\ninstances.\n"}, | |
| {"id": "416", "title": "Add a frozendict builtin type", "authors": "Stinner", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "29-Feb-2012", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0416/", "abstract": "\nAbstract\nAdd a new frozendict builtin type.\n"}, | |
| {"id": "417", "title": "Including mock in the Standard Library", "authors": "Foord", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "12-Mar-2012", "python_version": "3.3", "post_history": "12-Mar-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-March/117507.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0417/", "abstract": "\nAbstract\nThis PEP proposes adding the mock [1] testing library\nto the Python standard library as unittest.mock.\n"}, | |
| {"id": "418", "title": "Add monotonic time, performance counter, and process time functions", "authors": "Simpson, Jewett, Turnbull, Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Mar-2012", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0418/", "abstract": "\nAbstract\nThis PEP proposes to add time.get_clock_info(name),\ntime.monotonic(), time.perf_counter() and\ntime.process_time() functions to Python 3.3.\n"}, | |
| {"id": "419", "title": "Protecting cleanup statements from interruptions", "authors": "Colomiets", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "06-Apr-2012", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0419/", "abstract": "\nAbstract\nThis PEP proposes a way to protect Python code from being interrupted\ninside a finally clause or during context manager cleanup.\n"}, | |
| {"id": "420", "title": "Implicit Namespace Packages", "authors": "Smith", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Apr-2012", "python_version": "3.3", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2012-May/119651.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0420/", "abstract": "\nAbstract\nNamespace packages are a mechanism for splitting a single Python package\nacross multiple directories on disk. In current Python versions, an algorithm\nto compute the packages __path__ must be formulated. With the enhancement\nproposed here, the import machinery itself will construct the list of\ndirectories that make up the package. This PEP builds upon previous work,\ndocumented in PEP 382 and PEP 402. Those PEPs have since been rejected in\nfavor of this one. An implementation of this PEP is at [1].\n"}, | |
| {"id": "421", "title": "Adding sys.implementation", "authors": "Snow", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Apr-2012", "python_version": "3.3", "post_history": "26-Apr-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2012-May/119683.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0421/", "abstract": "\nAbstract\nThis PEP introduces a new attribute for the sys module:\nsys.implementation. The attribute holds consolidated information\nabout the implementation of the running interpreter. Thus\nsys.implementation is the source to which the standard library may\nlook for implementation-specific information.\nThe proposal in this PEP is in line with a broader emphasis on making\nPython friendlier to alternate implementations. It describes the new\nvariable and the constraints on what that variable contains. The PEP\nalso explains some immediate use cases for sys.implementation.\n"}, | |
| {"id": "422", "title": "Simpler customisation of class creation", "authors": "Coghlan, Urban", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "05-Jun-2012", "python_version": "3.5", "post_history": "05-Jun-2012, 10-Feb-2013", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0422/", "abstract": "\nAbstract\nCurrently, customising class creation requires the use of a custom metaclass.\nThis custom metaclass then persists for the entire lifecycle of the class,\ncreating the potential for spurious metaclass conflicts.\nThis PEP proposes to instead support a wide range of customisation\nscenarios through a new namespace parameter in the class header, and\na new __autodecorate__ hook in the class body.\nThe new mechanism should be easier to understand and use than\nimplementing a custom metaclass, and thus should provide a gentler\nintroduction to the full power Python's metaclass machinery.\n"}, | |
| {"id": "423", "title": "Naming conventions and recipes related to packaging", "authors": "Bryon", "discussions_to": "distutils-sig@python.org", "status": "Deferred", "type": "Informational", "topic": "packaging", "created": "24-May-2012", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0423/", "abstract": "\nAbstract\nThis document deals with:\n\nnames of Python projects,\nnames of Python packages or modules being distributed,\nnamespace packages.\n\nIt provides guidelines and recipes for distribution authors:\n\nnew projects should follow the guidelines below.\nexisting projects should be aware of these guidelines and can follow\nspecific recipes for existing projects.\n\n"}, | |
| {"id": "424", "title": "A method for exposing a length hint", "authors": "Gaynor", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "14-Jul-2012", "python_version": "3.4", "post_history": "`15-Jul-2012 <https://mail.python.org/pipermail/python-dev/2012-July/120920.html>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0424/", "abstract": "\nAbstract\nCPython currently defines a __length_hint__ method on several\ntypes, such as various iterators. This method is then used by various\nother functions (such as list) to presize lists based on the\nestimate returned by __length_hint__. Types which are not sized,\nand thus should not define __len__, can then define\n__length_hint__, to allow estimating or computing a size (such as\nmany iterators).\n"}, | |
| {"id": "425", "title": "Compatibility Tags for Built Distributions", "authors": "Holth", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "27-Jul-2012", "python_version": "3.4", "post_history": "08-Aug-2012, 18-Oct-2012, 15-Feb-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-February/124116.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0425/", "abstract": "\nAbstract\nThis PEP specifies a tagging system to indicate with which versions of\nPython a built or binary distribution is compatible. A set of three\ntags indicate which Python implementation and language version, ABI,\nand platform a built distribution requires. The tags are terse because\nthey will be included in filenames.\n"}, | |
| {"id": "426", "title": "Metadata for Python Software Packages 2.0", "authors": "Coghlan, Holth, Stufft", "discussions_to": "distutils-sig@python.org", "status": "Withdrawn", "type": "Informational", "topic": "packaging", "created": "30-Aug-2012", "python_version": null, "post_history": "14-Nov-2012, 05-Feb-2013, 07-Feb-2013, 09-Feb-2013, 27-May-2013, 20-Jun-2013, 23-Jun-2013, 14-Jul-2013, 21-Dec-2013", "resolution": null, "requires": "440, 508, 518", "replaces": "345", "superseded_by": null, "url": "https://peps.python.org/pep-0426/", "abstract": "\nAbstract\nThis PEP describes a mechanism for publishing and exchanging metadata\nrelated to Python distributions. It includes specifics of the field names,\nand their semantics and usage.\nThis document specifies the never released version 2.0 of the metadata format.\nVersion 1.0 is specified in PEP 241.\nVersion 1.1 is specified in PEP 314.\nVersion 1.2 is specified in PEP 345.\nVersion 2.0 of the metadata format proposed migrating from directly defining a\ncustom key-value file format to instead defining a JSON-compatible in-memory\nrepresentation that may be used to define metadata representation in other\ncontexts (such as API and archive format definitions).\nThis version also defines a formal extension mechanism, allowing new\nfields to be added for particular purposes without requiring updates to\nthe core metadata format.\n"}, | |
| {"id": "427", "title": "The Wheel Binary Package Format 1.0", "authors": "Holth", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "20-Sep-2012", "python_version": null, "post_history": "18-Oct-2012, 15-Feb-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-February/124103.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0427/", "abstract": "\nAbstract\nThis PEP describes a built-package format for Python called \"wheel\".\nA wheel is a ZIP-format archive with a specially formatted file name and\nthe .whl extension. It contains a single distribution nearly as it\nwould be installed according to PEP 376 with a particular installation\nscheme. Although a specialized installer is recommended, a wheel file\nmay be installed by simply unpacking into site-packages with the standard\n'unzip' tool while preserving enough information to spread its contents\nout onto their final paths at any later time.\n"}, | |
| {"id": "428", "title": "The pathlib module -- object-oriented filesystem paths", "authors": "Pitrou", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Jul-2012", "python_version": "3.4", "post_history": "`05-Oct-2012 <https://mail.python.org/pipermail/python-ideas/2012-October/016338.html>`__", "resolution": "https://mail.python.org/pipermail/python-dev/2013-November/130424.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0428/", "abstract": "\nAbstract\nThis PEP proposes the inclusion of a third-party module, pathlib, in\nthe standard library. The inclusion is proposed under the provisional\nlabel, as described in PEP 411. Therefore, API changes can be done,\neither as part of the PEP process, or after acceptance in the standard\nlibrary (and until the provisional label is removed).\nThe aim of this library is to provide a simple hierarchy of classes to\nhandle filesystem paths and the common operations users do over them.\n"}, | |
| {"id": "429", "title": "Python 3.4 Release Schedule", "authors": "Hastings", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "17-Oct-2012", "python_version": "3.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0429/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.4. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "430", "title": "Migrating to Python 3 as the default online documentation", "authors": "Coghlan", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "27-Oct-2012", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0430/", "abstract": "\nAbstract\nThis PEP proposes a strategy for migrating the default version of the\nPython documentation presented to users of Python when accessing\ndocs.python.org from 2.7 to Python 3.3.\nIt proposes a backwards compatible scheme that preserves the meaning of\nexisting deep links in to the Python 2 documentation, while still\npresenting the Python 3 documentation by default, and presenting the\nPython 2 and 3 documentation in a way that avoids making the Python 3\ndocumentation look like a second-class citizen.\n"}, | |
| {"id": "431", "title": "Time zone support improvements", "authors": "Regebro", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "", "created": "11-Dec-2012", "python_version": null, "post_history": "11-Dec-2012, 28-Dec-2012, 28-Jan-2013", "resolution": null, "requires": null, "replaces": null, "superseded_by": "615", "url": "https://peps.python.org/pep-0431/", "abstract": "\nAbstract\nThis PEP proposes the implementation of concrete time zone support in the\nPython standard library, and also improvements to the time zone API to deal\nwith ambiguous time specifications during DST changes.\n"}, | |
| {"id": "432", "title": "Restructuring the CPython startup sequence", "authors": "Coghlan, Stinner, Snow", "discussions_to": "capi-sig@python.org", "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "28-Dec-2012", "python_version": null, "post_history": "28-Dec-2012, 02-Jan-2013, 30-Mar-2019, 28-Jun-2020", "resolution": null, "requires": "587", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0432/", "abstract": "\nAbstract\nThis PEP proposes a mechanism for restructuring the startup sequence for\nCPython, making it easier to modify the initialization behaviour of the\nreference interpreter executable, as well as making it easier to control\nCPython's startup behaviour when creating an alternate executable or\nembedding it as a Python execution engine inside a larger application.\nWhen implementation of this proposal is completed, interpreter startup will\nconsist of three clearly distinct and independently configurable phases:\n\nPython core runtime preinitialization\nsetting up memory management\ndetermining the encodings used for system interfaces (including settings\npassed in for later configuration phase)\n\n\nPython core runtime initialization\nensuring C API is ready for use\nensuring builtin and frozen modules are accessible\n\n\nMain interpreter configuration\nensuring external modules are accessible\n(Note: the name of this phase is quite likely to change)\n\n\n\nChanges are also proposed that impact main module execution and subinterpreter\ninitialization.\nNote: TBC = To Be Confirmed, TBD = To Be Determined. The appropriate\nresolution for most of these should become clearer as the reference\nimplementation is developed.\n"}, | |
| {"id": "433", "title": "Easier suppression of file descriptor inheritance", "authors": "Stinner", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "", "created": "10-Jan-2013", "python_version": "3.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": "446", "url": "https://peps.python.org/pep-0433/", "abstract": "\nAbstract\nAdd a new optional cloexec parameter on functions creating file\ndescriptors, add different ways to change default values of this\nparameter, and add four new functions:\n\nos.get_cloexec(fd)\nos.set_cloexec(fd, cloexec=True)\nsys.getdefaultcloexec()\nsys.setdefaultcloexec(cloexec)\n\n"}, | |
| {"id": "434", "title": "IDLE Enhancement Exception for All Branches", "authors": "Rovito, Reedy", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "16-Feb-2013", "python_version": null, "post_history": "16-Feb-2013, 03-Mar-2013, 21-Mar-2013, 30-Mar-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-March/125003.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0434/", "abstract": "\nAbstract\nMost CPython tracker issues are classified as behavior or enhancement.\nMost behavior patches are backported to branches for existing\nversions. Enhancement patches are restricted to the default branch\nthat becomes the next Python version.\nThis PEP proposes that the restriction on applying enhancements be\nrelaxed for IDLE code, residing in .../Lib/idlelib/. In practice,\nthis would mean that IDLE developers would not have to classify or\nagree on the classification of a patch but could instead focus on what\nis best for IDLE users and future IDLE development. It would also\nmean that IDLE patches would not necessarily have to be split into\n'bugfix' changes and enhancement changes.\nThe PEP would apply to changes in existing features and addition of\nsmall features, such as would require a new menu entry, but not\nnecessarily to possible major re-writes such as switching to themed\nwidgets or tabbed windows.\n"}, | |
| {"id": "435", "title": "Adding an Enum type to the Python standard library", "authors": "Warsaw, Bendersky, Furman", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "23-Feb-2013", "python_version": "3.4", "post_history": "23-Feb-2013, 02-May-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-May/126112.html", "requires": null, "replaces": "354", "superseded_by": null, "url": "https://peps.python.org/pep-0435/", "abstract": "\nAbstract\nThis PEP proposes adding an enumeration type to the Python standard library.\nAn enumeration is a set of symbolic names bound to unique, constant values.\nWithin an enumeration, the values can be compared by identity, and the\nenumeration itself can be iterated over.\n"}, | |
| {"id": "436", "title": "The Argument Clinic DSL", "authors": "Hastings", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "22-Feb-2013", "python_version": "3.4", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0436/", "abstract": "\nAbstract\nThis document proposes \"Argument Clinic\", a DSL to facilitate\nargument processing for built-in functions in the implementation of\nCPython.\n"}, | |
| {"id": "437", "title": "A DSL for specifying signatures, annotations and argument converters", "authors": "Krah", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "11-Mar-2013", "python_version": "3.4", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2013-May/126117.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0437/", "abstract": "\nAbstract\nThe Python C-API currently has no mechanism for specifying and auto-generating\nfunction signatures, annotations or custom argument converters.\nThere are several possible approaches to the problem. Cython uses cdef\ndefinitions in .pyx files to generate the required information. However,\nCPython's C-API functions often require additional initialization and\ncleanup snippets that would be hard to specify in a cdef.\nPEP 436 proposes a domain specific language (DSL) enclosed in C comments\nthat largely resembles a per-parameter configuration file. A preprocessor\nreads the comment and emits an argument parsing function, docstrings and\na header for the function that utilizes the results of the parsing step.\nThe latter function is subsequently referred to as the implementation\nfunction.\n"}, | |
| {"id": "438", "title": "Transitioning to release-file hosting on PyPI", "authors": "Krekel, Meyer", "discussions_to": "distutils-sig@python.org", "status": "Superseded", "type": "Process", "topic": "packaging", "created": "15-Mar-2013", "python_version": null, "post_history": "19-May-2013", "resolution": "https://mail.python.org/pipermail/distutils-sig/2013-May/020773.html", "requires": null, "replaces": null, "superseded_by": "470", "url": "https://peps.python.org/pep-0438/", "abstract": "\nAbstract\nThis PEP proposes a backward-compatible two-phase transition process\nto speed up, simplify and robustify installing from the\npypi.python.org (PyPI) package index. To ease the transition and\nminimize client-side friction, no changes to distutils or existing\ninstallation tools are required in order to benefit from the first\ntransition phase, which will result in faster, more reliable installs\nfor most existing packages.\nThe first transition phase implements easy and explicit means for a\npackage maintainer to control which release file links are served to\npresent-day installation tools. The first phase also includes the\nimplementation of analysis tools for present-day packages, to support\ncommunication with package maintainers and the automated setting of\ndefault modes for controlling release file links. The first phase\nalso will default newly-registered projects on PyPI to only serve\nlinks to release files which were uploaded to PyPI.\nThe second transition phase concerns end-user installation tools,\nwhich shall default to only install release files that are hosted on\nPyPI and tell the user if external release files exist, offering a\nchoice to automatically use those external files. External release\nfiles shall in the future be registered together with a checksum\nhash so that installation tools can verify the integrity of the\neventual download (PyPI-hosted release files always carry such\na checksum).\nAlternative PyPI server implementations should implement the new\nsimple index serving behaviour of transition phase 1 to avoid\ninstallation tools treating their release links as external ones in\nphase 2.\n"}, | |
| {"id": "439", "title": "Inclusion of implicit pip bootstrap in Python installation", "authors": "Jones", "discussions_to": "distutils-sig@python.org", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "18-Mar-2013", "python_version": "3.4", "post_history": "19-Mar-2013", "resolution": "https://mail.python.org/pipermail/distutils-sig/2013-August/022527.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0439/", "abstract": "\nAbstract\nThis PEP proposes the inclusion of a pip bootstrap executable in the\nPython installation to simplify the use of 3rd-party modules by Python\nusers.\nThis PEP does not propose to include the pip implementation in the\nPython standard library. Nor does it propose to implement any package\nmanagement or installation mechanisms beyond those provided by PEP\n427 (\"The Wheel Binary Package Format 1.0\") and TODO distlib PEP.\n"}, | |
| {"id": "440", "title": "Version Identification and Dependency Specification", "authors": "Coghlan, Stufft", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "18-Mar-2013", "python_version": null, "post_history": "30-Mar-2013, 27-May-2013, 20-Jun-2013, 21-Dec-2013, 28-Jan-2014, 08-Aug-2014, 22-Aug-2014", "resolution": "https://mail.python.org/pipermail/distutils-sig/2014-August/024673.html", "requires": null, "replaces": "386", "superseded_by": null, "url": "https://peps.python.org/pep-0440/", "abstract": "\nAbstract\nThis PEP describes a scheme for identifying versions of Python software\ndistributions, and declaring dependencies on particular versions.\nThis document addresses several limitations of the previous attempt at a\nstandardized approach to versioning, as described in PEP 345 and PEP 386.\n"}, | |
| {"id": "441", "title": "Improving Python ZIP Application Support", "authors": "Holth, Moore", "discussions_to": "https://mail.python.org/pipermail/python-dev/2015-February/138277.html", "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Mar-2013", "python_version": "3.5", "post_history": "30-Mar-2013, 01-Apr-2013, 16-Feb-2015", "resolution": "https://mail.python.org/pipermail/python-dev/2015-February/138578.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0441/", "abstract": ""}, | |
| {"id": "442", "title": "Safe object finalization", "authors": "Pitrou", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "18-May-2013", "python_version": "3.4", "post_history": "18-May-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-June/126746.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0442/", "abstract": "\nAbstract\nThis PEP proposes to deal with the current limitations of object\nfinalization. The goal is to be able to define and run finalizers\nfor any object, regardless of their position in the object graph.\nThis PEP doesn't call for any change in Python code. Objects\nwith existing finalizers will benefit automatically.\n"}, | |
| {"id": "443", "title": "Single-dispatch generic functions", "authors": "Langa", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "22-May-2013", "python_version": "3.4", "post_history": "22-May-2013, 25-May-2013, 31-May-2013", "resolution": null, "requires": null, "replaces": "245, 246, 3124", "superseded_by": null, "url": "https://peps.python.org/pep-0443/", "abstract": "\nAbstract\nThis PEP proposes a new mechanism in the functools standard library\nmodule that provides a simple form of generic programming known as\nsingle-dispatch generic functions.\nA generic function is composed of multiple functions implementing\nthe same operation for different types. Which implementation should be\nused during a call is determined by the dispatch algorithm. When the\nimplementation is chosen based on the type of a single argument, this is\nknown as single dispatch.\n"}, | |
| {"id": "444", "title": "Python Web3 Interface", "authors": "McDonough, Ronacher", "discussions_to": "web-sig@python.org", "status": "Deferred", "type": "Informational", "topic": "", "created": "19-Jul-2010", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0444/", "abstract": "\nAbstract\nThis document specifies a proposed second-generation standard\ninterface between web servers and Python web applications or\nframeworks.\n"}, | |
| {"id": "445", "title": "Add new APIs to customize Python memory allocators", "authors": "Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Jun-2013", "python_version": "3.4", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2013-July/127222.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0445/", "abstract": "\nAbstract\nThis PEP proposes new Application Programming Interfaces (API) to customize\nPython memory allocators. The only implementation required to conform to\nthis PEP is CPython, but other implementations may choose to be compatible,\nor to re-use a similar scheme.\n"}, | |
| {"id": "446", "title": "Make newly created file descriptors non-inheritable", "authors": "Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Aug-2013", "python_version": "3.4", "post_history": null, "resolution": null, "requires": null, "replaces": "433", "superseded_by": null, "url": "https://peps.python.org/pep-0446/", "abstract": "\nAbstract\nLeaking file descriptors in child processes causes various annoying\nissues and is a known major security vulnerability. Using the\nsubprocess module with the close_fds parameter set to True is\nnot possible in all cases.\nThis PEP proposes to make all file descriptors created by Python\nnon-inheritable by default to reduce the risk of these issues. This PEP\nfixes also a race condition in multi-threaded applications on operating\nsystems supporting atomic flags to create non-inheritable file\ndescriptors.\nWe are aware of the code breakage this is likely to cause, and doing it\nanyway for the good of mankind. (Details in the section \"Backward\nCompatibility\" below.)\n"}, | |
| {"id": "447", "title": "Add __getdescriptor__ method to metaclass", "authors": "Oussoren", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "12-Jun-2013", "python_version": null, "post_history": "02-Jul-2013, 15-Jul-2013, 29-Jul-2013, 22-Jul-2015", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0447/", "abstract": "\nAbstract\nCurrently object.__getattribute__ and super.__getattribute__ peek\nin the __dict__ of classes on the MRO for a class when looking for\nan attribute. This PEP adds an optional __getdescriptor__ method to\na metaclass that replaces this behavior and gives more control over attribute\nlookup, especially when using a super object.\nThat is, the MRO walking loop in _PyType_Lookup and\nsuper.__getattribute__ gets changed from:\ndef lookup(mro_list, name):\n for cls in mro_list:\n if name in cls.__dict__:\n return cls.__dict__\n\n return NotFound\n\n\nto:\ndef lookup(mro_list, name):\n for cls in mro_list:\n try:\n return cls.__getdescriptor__(name)\n except AttributeError:\n pass\n\n return NotFound\n\n\nThe default implementation of __getdescriptor__ looks in the class\ndictionary:\nclass type:\n def __getdescriptor__(cls, name):\n try:\n return cls.__dict__[name]\n except KeyError:\n raise AttributeError(name) from None\n\n\n"}, | |
| {"id": "448", "title": "Additional Unpacking Generalizations", "authors": "Landau", "discussions_to": "python-ideas@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "29-Jun-2013", "python_version": "3.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0448/", "abstract": "\nAbstract\nThis PEP proposes extended usages of the * iterable unpacking\noperator and ** dictionary unpacking operators\nto allow unpacking in more positions, an arbitrary number of\ntimes, and in additional circumstances. Specifically,\nin function calls, in comprehensions and generator expressions, and\nin displays.\nFunction calls are proposed to support an arbitrary number of\nunpackings rather than just one:\n>>> print(*[1], *[2], 3)\n1 2 3\n>>> dict(**{'x': 1}, y=2, **{'z': 3})\n{'x': 1, 'y': 2, 'z': 3}\n\n\nUnpacking is proposed to be allowed inside tuple, list, set,\nand dictionary displays:\n>>> *range(4), 4\n(0, 1, 2, 3, 4)\n>>> [*range(4), 4]\n[0, 1, 2, 3, 4]\n>>> {*range(4), 4}\n{0, 1, 2, 3, 4}\n>>> {'x': 1, **{'y': 2}}\n{'x': 1, 'y': 2}\n\n\nIn dictionaries, later values will always override earlier ones:\n>>> {'x': 1, **{'x': 2}}\n{'x': 2}\n\n>>> {**{'x': 2}, 'x': 1}\n{'x': 1}\n\n\nThis PEP does not include unpacking operators inside list, set and\ndictionary comprehensions although this has not been ruled out for\nfuture proposals.\n"}, | |
| {"id": "449", "title": "Removal of the PyPI Mirror Auto Discovery and Naming Scheme", "authors": "Stufft", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Process", "topic": "packaging", "created": "04-Aug-2013", "python_version": null, "post_history": "04-Aug-2013", "resolution": "https://mail.python.org/pipermail/distutils-sig/2013-August/022518.html", "requires": null, "replaces": "381", "superseded_by": null, "url": "https://peps.python.org/pep-0449/", "abstract": "\nAbstract\nThis PEP provides a path to deprecate and ultimately remove the auto discovery\nof PyPI mirrors as well as the hard coded naming scheme which requires\ndelegating a domain name under pypi.python.org to a third party.\n"}, | |
| {"id": "450", "title": "Adding A Statistics Module To The Standard Library", "authors": "D'Aprano", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-Aug-2013", "python_version": "3.4", "post_history": "13-Sep-2013", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0450/", "abstract": "\nAbstract\nThis PEP proposes the addition of a module for common statistics functions such\nas mean, median, variance and standard deviation to the Python standard\nlibrary. See also http://bugs.python.org/issue18606\n"}, | |
| {"id": "451", "title": "A ModuleSpec Type for the Import System", "authors": "Snow", "discussions_to": "import-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "08-Aug-2013", "python_version": "3.4", "post_history": "08-Aug-2013, 28-Aug-2013, 18-Sep-2013, 24-Sep-2013, 04-Oct-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-November/130104.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0451/", "abstract": "\nAbstract\nThis PEP proposes to add a new class to importlib.machinery called\n\"ModuleSpec\". It will provide all the import-related information used\nto load a module and will be available without needing to load the\nmodule first. Finders will directly provide a module's spec instead of\na loader (which they will continue to provide indirectly). The import\nmachinery will be adjusted to take advantage of module specs, including\nusing them to load modules.\n"}, | |
| {"id": "452", "title": "API for Cryptographic Hash Functions v2.0", "authors": "Kuchling, Heimes", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "15-Aug-2013", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": "247", "superseded_by": null, "url": "https://peps.python.org/pep-0452/", "abstract": "\nAbstract\nThere are several different modules available that implement\ncryptographic hashing algorithms such as MD5 or SHA. This\ndocument specifies a standard API for such algorithms, to make it\neasier to switch between different implementations.\n"}, | |
| {"id": "453", "title": "Explicit bootstrapping of pip in Python installations", "authors": "Stufft, Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "10-Aug-2013", "python_version": null, "post_history": "30-Aug-2013, 15-Sep-2013, 18-Sep-2013, 19-Sep-2013, 23-Sep-2013, 29-Sep-2013, 13-Oct-2013, 20-Oct-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-October/129810.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0453/", "abstract": "\nAbstract\nThis PEP proposes that the\nInstalling Python Modules guide in\nPython 2.7, 3.3 and 3.4 be updated to officially recommend the use of pip\nas the default installer for Python packages, and that appropriate technical\nchanges be made in Python 3.4 to provide pip by default in support of\nthat recommendation.\n"}, | |
| {"id": "454", "title": "Add a new tracemalloc module to trace Python memory allocations", "authors": "Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "03-Sep-2013", "python_version": "3.4", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2013-November/130491.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0454/", "abstract": "\nAbstract\nThis PEP proposes to add a new tracemalloc module to trace memory\nblocks allocated by Python.\n"}, | |
| {"id": "455", "title": "Adding a key-transforming dictionary to collections", "authors": "Pitrou", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "13-Sep-2013", "python_version": "3.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0455/", "abstract": "\nAbstract\nThis PEP proposes a new data structure for the collections module,\ncalled \"TransformDict\" in this PEP. This structure is a mutable mapping\nwhich transforms the key using a given function when doing a lookup, but\nretains the original key when reading.\n\nRejection\nSee the rationale at\nhttps://mail.python.org/pipermail/python-dev/2015-May/140003.html\nand for an earlier partial review, see\nhttps://mail.python.org/pipermail/python-dev/2013-October/129937.html .\n\n"}, | |
| {"id": "456", "title": "Secure and interchangeable hash algorithm", "authors": "Heimes", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Sep-2013", "python_version": "3.4", "post_history": "06-Oct-2013, 14-Nov-2013, 20-Nov-2013", "resolution": "https://mail.python.org/pipermail/python-dev/2013-November/130400.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0456/", "abstract": "\nAbstract\nThis PEP proposes SipHash as default string and bytes hash algorithm to properly\nfix hash randomization once and for all. It also proposes modifications to\nPython's C code in order to unify the hash code and to make it easily\ninterchangeable.\n"}, | |
| {"id": "457", "title": "Notation For Positional-Only Parameters", "authors": "Hastings", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "08-Oct-2013", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0457/", "abstract": ""}, | |
| {"id": "458", "title": "Secure PyPI downloads with signed repository metadata", "authors": "Kuppusamy, Diaz, Moore, Puehringer, Lock, DeLong, Cappos", "discussions_to": "https://discuss.python.org/t/pep-458-secure-pypi-downloads-with-package-signing/2648", "status": "Accepted", "type": "Standards Track", "topic": "packaging", "created": "27-Sep-2013", "python_version": null, "post_history": "06-Jan-2019, 13-Nov-2019", "resolution": "https://discuss.python.org/t/pep-458-secure-pypi-downloads-with-package-signing/2648/115", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0458/", "abstract": "\nAbstract\nThis PEP describes changes to the PyPI infrastructure that are needed to ensure\nthat users get valid packages from PyPI. These changes should have minimal\nimpact on other parts of the ecosystem. The PEP focuses on communication between\nPyPI and users, and so does not require any action by package developers.\nDevelopers will upload packages using the current process, and PyPI will\nautomatically generate signed repository metadata for these packages.\nIn order for the security mechanism to be\neffective, additional work will need to be done by PyPI consumers (like pip) to\nverify the signatures and metadata provided by PyPI. This verification can be\ntransparent to users (unless it fails) and provides an automatic security\nmechanism. There is documentation for how to consume TUF metadata in the TUF\nrepository. However, changes to PyPI consumers are not a pre-requisite for\npublishing the metadata from PyPI, and can be done\naccording to the timelines and priorities of individual projects.\n"}, | |
| {"id": "459", "title": "Standard Metadata Extensions for Python Software Packages", "authors": "Coghlan", "discussions_to": "distutils-sig@python.org", "status": "Withdrawn", "type": "Standards Track", "topic": "packaging", "created": "11-Nov-2013", "python_version": null, "post_history": "21-Dec-2013", "resolution": null, "requires": "426", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0459/", "abstract": "\nAbstract\nThis PEP describes several standard extensions to the Python metadata.\nLike all metadata extensions, each standard extension format is\nindependently versioned. Changing any of the formats requires an update\nto this PEP, but does not require an update to the core packaging metadata.\n"}, | |
| {"id": "460", "title": "Add binary interpolation and formatting", "authors": "Pitrou", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "06-Jan-2014", "python_version": "3.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0460/", "abstract": "\nAbstract\nThis PEP proposes to add minimal formatting operations to bytes and\nbytearray objects. The proposed additions are:\n\nbytes % ... and bytearray % ... for percent-formatting,\nsimilar in syntax to percent-formatting on str objects\n(accepting a single object, a tuple or a dict).\nbytes.format(...) and bytearray.format(...) for a formatting\nsimilar in syntax to str.format() (accepting positional as well as\nkeyword arguments).\nbytes.format_map(...) and bytearray.format_map(...) for an\nAPI similar to str.format_map(...), with the same formatting\nsyntax and semantics as bytes.format() and bytearray.format().\n\n"}, | |
| {"id": "461", "title": "Adding % formatting to bytes and bytearray", "authors": "Furman", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "13-Jan-2014", "python_version": "3.5", "post_history": "14-Jan-2014, 15-Jan-2014, 17-Jan-2014, 22-Feb-2014, 25-Mar-2014, 27-Mar-2014", "resolution": "https://mail.python.org/pipermail/python-dev/2014-March/133621.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0461/", "abstract": "\nAbstract\nThis PEP proposes adding % formatting operations similar to Python 2's str\ntype to bytes and bytearray [1] [2].\n"}, | |
| {"id": "462", "title": "Core development workflow automation for CPython", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "23-Jan-2014", "python_version": null, "post_history": "25-Jan-2014, 27-Jan-2014, 01-Feb-2015", "resolution": null, "requires": "474", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0462/", "abstract": "\nAbstract\nThis PEP proposes investing in automation of several of the tedious,\ntime-consuming activities that are currently required for the core development\nteam to incorporate changes into CPython. This proposal is intended to\nallow core developers to make more effective use of the time they have\navailable to contribute to CPython, which should also result in an improved\nexperience for other contributors that are reliant on the core team to get\ntheir changes incorporated.\n"}, | |
| {"id": "463", "title": "Exception-catching expressions", "authors": "Angelico", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "15-Feb-2014", "python_version": "3.5", "post_history": "20-Feb-2014, 16-Feb-2014", "resolution": "https://mail.python.org/pipermail/python-dev/2014-March/133118.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0463/", "abstract": "\nAbstract\nJust as PEP 308 introduced a means of value-based conditions in an\nexpression, this system allows exception-based conditions to be used\nas part of an expression.\n"}, | |
| {"id": "464", "title": "Removal of the PyPI Mirror Authenticity API", "authors": "Stufft", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Process", "topic": "packaging", "created": "02-Mar-2014", "python_version": null, "post_history": "04-Mar-2014", "resolution": "https://mail.python.org/pipermail/distutils-sig/2014-March/024027.html", "requires": null, "replaces": "381", "superseded_by": null, "url": "https://peps.python.org/pep-0464/", "abstract": "\nAbstract\nThis PEP proposes the deprecation and removal of the PyPI Mirror Authenticity\nAPI, this includes the /serverkey URL and all of the URLs under /serversig.\n"}, | |
| {"id": "465", "title": "A dedicated infix operator for matrix multiplication", "authors": "Smith", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "20-Feb-2014", "python_version": "3.5", "post_history": "13-Mar-2014", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/D63NDWHPF7OC2Z455MPHOW6QLLSNQUJ5/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0465/", "abstract": "\nAbstract\nThis PEP proposes a new binary operator to be used for matrix\nmultiplication, called @. (Mnemonic: @ is * for\nmATrices.)\n"}, | |
| {"id": "466", "title": "Network Security Enhancements for Python 2.7.x", "authors": "Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "23-Mar-2014", "python_version": "2.7.9", "post_history": "23-Mar-2014, 24-Mar-2014, 25-Mar-2014, 26-Mar-2014, 16-Apr-2014", "resolution": "https://mail.python.org/pipermail/python-dev/2014-April/134163.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0466/", "abstract": "\nAbstract\nMost CPython tracker issues are classified as errors in behaviour or\nproposed enhancements. Most patches to fix behavioural errors are\napplied to all active maintenance branches. Enhancement patches are\nrestricted to the default branch that becomes the next Python version.\nThis cadence works reasonably well during Python's normal 18-24 month\nfeature release cycle, which is still applicable to the Python 3 series.\nHowever, the age of the standard library in Python 2 has now reached a point\nwhere it is sufficiently far behind the state of the art in network security\nprotocols for it to be causing real problems in use cases where upgrading to\nPython 3 in the near term may not be feasible.\nIn recognition of the additional practical considerations that have arisen\nduring the 4+ year maintenance cycle for Python 2.7, this PEP allows a\ncritical set of network security related features to be backported from\nPython 3.4 to upcoming Python 2.7.x maintenance releases.\nWhile this PEP does not make any changes to the core development team's\nhandling of security-fix-only branches that are no longer in active\nmaintenance, it does recommend that commercial redistributors providing\nextended support periods for the Python standard library either backport\nthese features to their supported versions, or else explicitly disclaim\nsupport for the use of older versions in roles that involve connecting\ndirectly to the public internet.\n"}, | |
| {"id": "467", "title": "Minor API improvements for binary sequences", "authors": "Coghlan, Furman", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "", "created": "30-Mar-2014", "python_version": "3.12", "post_history": "30-Mar-2014, 15-Aug-2014, 16-Aug-2014, 07-Jun-2016, 01-Sep-2016, 13-Apr-2021, 03-Nov-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0467/", "abstract": "\nAbstract\nThis PEP proposes five small adjustments to the APIs of the bytes and\nbytearray types to make it easier to operate entirely in the binary domain:\n\nAdd fromsize alternative constructor\nAdd fromint alternative constructor\nAdd ascii alternative constructor\nAdd getbyte byte retrieval method\nAdd iterbytes alternative iterator\n\n"}, | |
| {"id": "468", "title": "Preserving the order of \\*\\*kwargs in a function.", "authors": "Snow", "discussions_to": "python-ideas@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Apr-2014", "python_version": "3.6", "post_history": "05-Apr-2014, 08-Sep-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-September/146329.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0468/", "abstract": "\nAbstract\nThe **kwargs syntax in a function definition indicates that the\ninterpreter should collect all keyword arguments that do not correspond\nto other named parameters. However, Python does not preserved the\norder in which those collected keyword arguments were passed to the\nfunction. In some contexts the order matters. This PEP dictates that\nthe collected keyword arguments be exposed in the function body as an\nordered mapping.\n"}, | |
| {"id": "469", "title": "Migration of dict iteration code to Python 3", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "18-Apr-2014", "python_version": "3.5", "post_history": "18-Apr-2014, 21-Apr-2014", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0469/", "abstract": "\nAbstract\nFor Python 3, PEP 3106 changed the design of the dict builtin and the\nmapping API in general to replace the separate list based and iterator based\nAPIs in Python 2 with a merged, memory efficient set and multiset view\nbased API. This new style of dict iteration was also added to the Python 2.7\ndict type as a new set of iteration methods.\nThis means that there are now 3 different kinds of dict iteration that may\nneed to be migrated to Python 3 when an application makes the transition:\n\nLists as mutable snapshots: d.items() -> list(d.items())\nIterator objects: d.iteritems() -> iter(d.items())\nSet based dynamic views: d.viewitems() -> d.items()\n\nThere is currently no widely agreed best practice on how to reliably convert\nall Python 2 dict iteration code to the common subset of Python 2 and 3,\nespecially when test coverage of the ported code is limited. This PEP\nreviews the various ways the Python 2 iteration APIs may be accessed, and\nlooks at the available options for migrating that code to Python 3 by way of\nthe common subset of Python 2.6+ and Python 3.0+.\nThe PEP also considers the question of whether or not there are any\nadditions that may be worth making to Python 3.5 that may ease the\ntransition process for application code that doesn't need to worry about\nsupporting earlier versions when eventually making the leap to Python 3.\n"}, | |
| {"id": "470", "title": "Removing External Hosting Support on PyPI", "authors": "Stufft", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Process", "topic": "packaging", "created": "12-May-2014", "python_version": null, "post_history": "14-May-2014, 05-Jun-2014, 03-Oct-2014, 13-Oct-2014, 26-Aug-2015", "resolution": "https://mail.python.org/pipermail/distutils-sig/2015-September/026789.html", "requires": null, "replaces": "438", "superseded_by": null, "url": "https://peps.python.org/pep-0470/", "abstract": "\nAbstract\nThis PEP proposes the deprecation and removal of support for hosting files\nexternally to PyPI as well as the deprecation and removal of the functionality\nadded by PEP 438, particularly rel information to classify different types of\nlinks and the meta-tag to indicate API version.\n"}, | |
| {"id": "471", "title": "os.scandir() function -- a better and faster directory iterator", "authors": "Hoyt", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-May-2014", "python_version": "3.5", "post_history": "27-Jun-2014, 08-Jul-2014, 14-Jul-2014", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0471/", "abstract": "\nAbstract\nThis PEP proposes including a new directory iteration function,\nos.scandir(), in the standard library. This new function adds\nuseful functionality and increases the speed of os.walk() by 2-20\ntimes (depending on the platform and file system) by avoiding calls to\nos.stat() in most cases.\n"}, | |
| {"id": "472", "title": "Support for indexing with keyword arguments", "authors": "Borini, Martinot-Lagarde", "discussions_to": "python-ideas@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "24-Jun-2014", "python_version": "3.6", "post_history": "02-Jul-2014", "resolution": "https://mail.python.org/pipermail/python-dev/2019-March/156693.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0472/", "abstract": "\nAbstract\nThis PEP proposes an extension of the indexing operation to support keyword\narguments. Notations in the form a[K=3,R=2] would become legal syntax.\nFor future-proofing considerations, a[1:2, K=3, R=4] are considered and\nmay be allowed as well, depending on the choice for implementation. In addition\nto a change in the parser, the index protocol (__getitem__, __setitem__\nand __delitem__) will also potentially require adaptation.\n"}, | |
| {"id": "473", "title": "Adding structured data to built-in exceptions", "authors": "Kreft", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "29-Mar-2014", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2019-March/156692.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0473/", "abstract": "\nAbstract\nExceptions like AttributeError, IndexError, KeyError,\nLookupError, NameError, TypeError, and ValueError do not\nprovide all information required by programmers to debug and better understand\nwhat caused them.\nFurthermore, in some cases the messages even have slightly different formats,\nwhich makes it really difficult for tools to automatically provide additional\ninformation to diagnose the problem.\nTo tackle the former and to lay ground for the latter, it is proposed to expand\nthese exceptions so to hold both the offending and affected entities.\n"}, | |
| {"id": "474", "title": "Creating forge.python.org", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "19-Jul-2014", "python_version": null, "post_history": "19-Jul-2014, 08-Jan-2015, 01-Feb-2015", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0474/", "abstract": "\nAbstract\nThis PEP proposes setting up a new PSF provided resource, forge.python.org,\nas a location for maintaining various supporting repositories\n(such as the repository for Python Enhancement Proposals) in a way that is\nmore accessible to new contributors, and easier to manage for core\ndevelopers.\nThis PEP does not propose any changes to the core development workflow\nfor CPython itself (see PEP 462 in relation to that).\n"}, | |
| {"id": "475", "title": "Retry system calls failing with EINTR", "authors": "Natali, Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "29-Jul-2014", "python_version": "3.5", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2015-February/138018.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0475/", "abstract": "\nAbstract\nSystem call wrappers provided in the standard library should be retried\nautomatically when they fail with EINTR, to relieve application code\nfrom the burden of doing so.\nBy system calls, we mean the functions exposed by the standard C library\npertaining to I/O or handling of other system resources.\n"}, | |
| {"id": "476", "title": "Enabling certificate verification by default for stdlib http clients", "authors": "Gaynor", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Aug-2014", "python_version": "2.7.9, 3.4.3, 3.5", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2014-October/136676.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0476/", "abstract": "\nAbstract\nCurrently when a standard library http client (the urllib, urllib2,\nhttp, and httplib modules) encounters an https:// URL it will wrap\nthe network HTTP traffic in a TLS stream, as is necessary to communicate with\nsuch a server. However, during the TLS handshake it will not actually check\nthat the server has an X509 certificate is signed by a CA in any trust root,\nnor will it verify that the Common Name (or Subject Alternate Name) on the\npresented certificate matches the requested host.\nThe failure to do these checks means that anyone with a privileged network\nposition is able to trivially execute a man in the middle attack against a\nPython application using either of these HTTP clients, and change traffic at\nwill.\nThis PEP proposes to enable verification of X509 certificate signatures, as\nwell as hostname verification for Python's HTTP clients by default, subject to\nopt-out on a per-call basis. This change would be applied to Python 2.7, Python\n3.4, and Python 3.5.\n"}, | |
| {"id": "477", "title": "Backport ensurepip (PEP 453) to Python 2.7", "authors": "Stufft, Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Aug-2014", "python_version": null, "post_history": "01-Sep-2014", "resolution": "https://mail.python.org/pipermail/python-dev/2014-September/136238.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0477/", "abstract": "\nAbstract\nThis PEP proposes that the ensurepip module, added to Python 3.4 by PEP\n453, be backported to Python 2.7. It also proposes that automatic invocation\nof ensurepip be added to the Python 2.7 Windows and OSX installers. However\nit does not propose that automatic invocation be added to the Makefile.\nIt also proposes that the documentation changes for the package distribution\nand installation guides be updated to match that in 3.4, which references using\nthe ensurepip module to bootstrap the installer.\n"}, | |
| {"id": "478", "title": "Python 3.5 Release Schedule", "authors": "Hastings", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "22-Sep-2014", "python_version": "3.5", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0478/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.5. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "479", "title": "Change StopIteration handling inside generators", "authors": "Angelico, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Nov-2014", "python_version": "3.5", "post_history": "15-Nov-2014, 19-Nov-2014, 05-Dec-2014", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0479/", "abstract": "\nAbstract\nThis PEP proposes a change to generators: when StopIteration is\nraised inside a generator, it is replaced with RuntimeError.\n(More precisely, this happens when the exception is about to bubble\nout of the generator's stack frame.) Because the change is backwards\nincompatible, the feature is initially introduced using a\n__future__ statement.\n"}, | |
| {"id": "480", "title": "Surviving a Compromise of PyPI: End-to-end signing of packages", "authors": "Kuppusamy, Diaz, Cappos, Moore", "discussions_to": "https://discuss.python.org/t/5666", "status": "Draft", "type": "Standards Track", "topic": "packaging", "created": "08-Oct-2014", "python_version": null, "post_history": null, "resolution": null, "requires": "458", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0480/", "abstract": "\nAbstract\nProposed is an extension to PEP 458 that adds support for end-to-end signing\nand the maximum security model. End-to-end signing allows both PyPI and\ndevelopers to sign for the distributions that are downloaded by clients. The\nminimum security model proposed by PEP 458 supports continuous delivery of\ndistributions (because they are signed by online keys), but that model does not\nprotect distributions in the event that PyPI is compromised. In the minimum\nsecurity model, attackers who have compromised the signing keys stored on PyPI\nInfrastructure may sign for malicious distributions. The maximum security model,\ndescribed in this PEP, retains the benefits of PEP 458 (e.g., immediate\navailability of distributions that are uploaded to PyPI), but additionally\nensures that end-users are not at risk of installing forged software if PyPI is\ncompromised.\nThis PEP requires some changes to the PyPI infrastructure, and some suggested\nchanges for developers who wish to participate in end-to-end signing. These\nchanges include updating the metadata layout from PEP 458 to include delegations\nto developer keys, adding a process to register developer keys with PyPI, and a\nchange in the upload workflow for developers who take advantage of end-to-end\nsigning. All of these changes are described in detail later in this PEP. Package\nmanagers that wish to take advantage of end-to-end signing do not need to do any\nadditional work beyond what is required to consume metadata described in PEP\n458.\nThis PEP discusses the changes made to PEP 458 but excludes its informational\nelements to primarily focus on the maximum security model. For example, an\noverview of The Update Framework or the basic mechanisms in PEP 458 are not\ncovered here. The changes to PEP 458 include modifications to the snapshot\nprocess, key compromise analysis, auditing snapshots, and the steps that should\nbe taken in the event of a PyPI compromise. The signing and key management\nprocess that PyPI MAY RECOMMEND is discussed but not strictly defined. How the\nrelease process should be implemented to manage keys and metadata is left to\nthe implementors of the signing tools. That is, this PEP delineates the\nexpected cryptographic key type and signature format included in metadata that\nMUST be uploaded by developers in order to support end-to-end verification of\ndistributions.\n"}, | |
| {"id": "481", "title": "Migrate CPython to Git, Github, and Phabricator", "authors": "Stufft", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "29-Nov-2014", "python_version": null, "post_history": "29-Nov-2014", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0481/", "abstract": "\nAbstract\n\nNote\nThis PEP has been withdrawn, if you're looking for the PEP\ndocumenting the move to Github, please refer to PEP 512.\n\nThis PEP proposes migrating the repository hosting of CPython and the\nsupporting repositories to Git and Github. It also proposes adding Phabricator\nas an alternative to Github Pull Requests to handle reviewing changes. This\nparticular PEP is offered as an alternative to PEP 474 and PEP 462 which aims\nto achieve the same overall benefits but restricts itself to tools that support\nMercurial and are completely Open Source.\n"}, | |
| {"id": "482", "title": "Literature Overview for Type Hints", "authors": "Langa", "discussions_to": "python-ideas@python.org", "status": "Final", "type": "Informational", "topic": "typing", "created": "08-Jan-2015", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0482/", "abstract": "\nAbstract\nThis PEP is one of three related to type hinting. This PEP gives a\nliterature overview of related work. The main spec is PEP 484.\n"}, | |
| {"id": "483", "title": "The Theory of Type Hints", "authors": "GvR, Levkivskyi", "discussions_to": "python-ideas@python.org", "status": "Final", "type": "Informational", "topic": "typing", "created": "19-Dec-2014", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0483/", "abstract": "\nIntroduction\nThis document lays out the theory of the new type hinting proposal for\nPython 3.5. It's not quite a full proposal or specification because\nthere are many details that need to be worked out, but it lays out the\ntheory without which it is hard to discuss more detailed specifications.\nWe start by recalling basic concepts of type theory; then we explain\ngradual typing; then we state some general rules and\ndefine the new special types (such as Union) that can be used\nin annotations; and finally we define the approach to generic types\nand pragmatic aspects of type hinting.\n\nNotational conventions\n\nt1, t2, etc. and u1, u2, etc. are types. Sometimes we write\nti or tj to refer to \"any of t1, t2, etc.\"\nT, U etc. are type variables (defined with TypeVar(), see below).\nObjects, classes defined with a class statement, and instances are\ndenoted using standard PEP 8 conventions.\nthe symbol == applied to types in the context of this PEP means that\ntwo expressions represent the same type.\nNote that PEP 484 makes a distinction between types and classes\n(a type is a concept for the type checker,\nwhile a class is a runtime concept). In this PEP we clarify\nthis distinction but avoid unnecessary strictness to allow more\nflexibility in the implementation of type checkers.\n\n\n"}, | |
| {"id": "484", "title": "Type Hints", "authors": "GvR, Lehtosalo, Langa", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Standards Track", "topic": "typing", "created": "29-Sep-2014", "python_version": "3.5", "post_history": "16-Jan-2015, 20-Mar-2015, 17-Apr-2015, 20-May-2015, 22-May-2015", "resolution": "https://mail.python.org/pipermail/python-dev/2015-May/140104.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0484/", "abstract": "\nAbstract\nPEP 3107 introduced syntax for function annotations, but the semantics\nwere deliberately left undefined. There has now been enough 3rd party\nusage for static type analysis that the community would benefit from\na standard vocabulary and baseline tools within the standard library.\nThis PEP introduces a provisional module to provide these standard\ndefinitions and tools, along with some conventions for situations\nwhere annotations are not available.\nNote that this PEP still explicitly does NOT prevent other uses of\nannotations, nor does it require (or forbid) any particular processing\nof annotations, even when they conform to this specification. It\nsimply enables better coordination, as PEP 333 did for web frameworks.\nFor example, here is a simple function whose argument and return type\nare declared in the annotations:\ndef greeting(name: str) -> str:\n return 'Hello ' + name\n\n\nWhile these annotations are available at runtime through the usual\n__annotations__ attribute, no type checking happens at runtime.\nInstead, the proposal assumes the existence of a separate off-line\ntype checker which users can run over their source code voluntarily.\nEssentially, such a type checker acts as a very powerful linter.\n(While it would of course be possible for individual users to employ\na similar checker at run time for Design By Contract enforcement or\nJIT optimization, those tools are not yet as mature.)\nThe proposal is strongly inspired by mypy. For example, the\ntype \"sequence of integers\" can be written as Sequence[int]. The\nsquare brackets mean that no new syntax needs to be added to the\nlanguage. The example here uses a custom type Sequence, imported\nfrom a pure-Python module typing. The Sequence[int] notation\nworks at runtime by implementing __getitem__() in the metaclass\n(but its significance is primarily to an offline type checker).\nThe type system supports unions, generic types, and a special type\nnamed Any which is consistent with (i.e. assignable to and from) all\ntypes. This latter feature is taken from the idea of gradual typing.\nGradual typing and the full type system are explained in PEP 483.\nOther approaches from which we have borrowed or to which ours can be\ncompared and contrasted are described in PEP 482.\n"}, | |
| {"id": "485", "title": "A Function for testing approximate equality", "authors": "Barker", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "20-Jan-2015", "python_version": "3.5", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2015-February/138598.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0485/", "abstract": "\nAbstract\nThis PEP proposes the addition of an isclose() function to the standard\nlibrary math module that determines whether one value is approximately equal\nor \"close\" to another value.\n"}, | |
| {"id": "486", "title": "Make the Python Launcher aware of virtual environments", "authors": "Moore", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "12-Feb-2015", "python_version": "3.5", "post_history": "12-Feb-2015", "resolution": "https://mail.python.org/pipermail/python-dev/2015-February/138579.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0486/", "abstract": "\nAbstract\nThe Windows installers for Python include a launcher that locates the\ncorrect Python interpreter to run (see PEP 397). However, the\nlauncher is not aware of virtual environments (virtualenv [1] or PEP\n405 based), and so cannot be used to run commands from the active\nvirtualenv.\nThis PEP proposes making the launcher \"virtualenv aware\". This means\nthat when run without specifying an explicit Python interpreter to\nuse, the launcher will use the currently active virtualenv, if any,\nbefore falling back to the configured default Python.\n"}, | |
| {"id": "487", "title": "Simpler customisation of class creation", "authors": "Teichmann", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Feb-2015", "python_version": "3.6", "post_history": "27-Feb-2015, 05-Feb-2016, 24-Jun-2016, 02-Jul-2016, 13-Jul-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-July/145629.html", "requires": null, "replaces": "422", "superseded_by": null, "url": "https://peps.python.org/pep-0487/", "abstract": "\nAbstract\nCurrently, customising class creation requires the use of a custom metaclass.\nThis custom metaclass then persists for the entire lifecycle of the class,\ncreating the potential for spurious metaclass conflicts.\nThis PEP proposes to instead support a wide range of customisation\nscenarios through a new __init_subclass__ hook in the class body,\nand a hook to initialize attributes.\nThe new mechanism should be easier to understand and use than\nimplementing a custom metaclass, and thus should provide a gentler\nintroduction to the full power of Python's metaclass machinery.\n"}, | |
| {"id": "488", "title": "Elimination of PYO files", "authors": "Cannon", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "20-Feb-2015", "python_version": "3.5", "post_history": "06-Mar-2015, 13-Mar-2015, 20-Mar-2015", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0488/", "abstract": "\nAbstract\nThis PEP proposes eliminating the concept of PYO files from Python.\nTo continue the support of the separation of bytecode files based on\ntheir optimization level, this PEP proposes extending the PYC file\nname to include the optimization level in the bytecode repository\ndirectory when there are optimizations applied.\n"}, | |
| {"id": "489", "title": "Multi-phase extension module initialization", "authors": "Viktorin, Behnel, Coghlan", "discussions_to": "import-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "11-Aug-2013", "python_version": "3.5", "post_history": "23-Aug-2013, 20-Feb-2015, 16-Apr-2015, 07-May-2015, 18-May-2015", "resolution": "https://mail.python.org/pipermail/python-dev/2015-May/140108.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0489/", "abstract": "\nAbstract\nThis PEP proposes a redesign of the way in which built-in and extension modules\ninteract with the import machinery. This was last revised for Python 3.0 in PEP\n3121, but did not solve all problems at the time. The goal is to solve\nimport-related problems by bringing extension modules closer to the way Python\nmodules behave; specifically to hook into the ModuleSpec-based loading\nmechanism introduced in PEP 451.\nThis proposal draws inspiration from PyType_Spec of PEP 384 to allow extension\nauthors to only define features they need, and to allow future additions\nto extension module declarations.\nExtensions modules are created in a two-step process, fitting better into\nthe ModuleSpec architecture, with parallels to __new__ and __init__ of classes.\nExtension modules can safely store arbitrary C-level per-module state in\nthe module that is covered by normal garbage collection and supports\nreloading and sub-interpreters.\nExtension authors are encouraged to take these issues into account\nwhen using the new API.\nThe proposal also allows extension modules with non-ASCII names.\nNot all problems tackled in PEP 3121 are solved in this proposal.\nIn particular, problems with run-time module lookup (PyState_FindModule)\nare left to a future PEP.\n"}, | |
| {"id": "490", "title": "Chain exceptions at C level", "authors": "Stinner", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "25-Mar-2015", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0490/", "abstract": "\nAbstract\nChain exceptions at C level, as already done at Python level.\n"}, | |
| {"id": "491", "title": "The Wheel Binary Package Format 1.9", "authors": "Holth", "discussions_to": "distutils-sig@python.org", "status": "Deferred", "type": "Standards Track", "topic": "packaging", "created": "16-Apr-2015", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0491/", "abstract": "\nAbstract\nThis PEP describes the second version of a built-package format for Python\ncalled \"wheel\". Wheel provides a Python-specific, relocatable package format\nthat allows people to install software more quickly and predictably than\nre-building from source each time.\nA wheel is a ZIP-format archive with a specially formatted file name and\nthe .whl extension. It contains a single distribution nearly as it\nwould be installed according to PEP 376 with a particular installation\nscheme. Simple wheels can be unpacked onto sys.path and used directly\nbut wheels are usually installed with a specialized installer.\nThis version of the wheel specification adds support for installing\ndistributions into many different directories, and adds a way to find\nthose files after they have been installed.\n"}, | |
| {"id": "492", "title": "Coroutines with async and await syntax", "authors": "Selivanov", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "09-Apr-2015", "python_version": "3.5", "post_history": "17-Apr-2015, 21-Apr-2015, 27-Apr-2015, 29-Apr-2015, 05-May-2015", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0492/", "abstract": "\nAbstract\nThe growth of Internet and general connectivity has triggered the\nproportionate need for responsive and scalable code. This proposal\naims to answer that need by making writing explicitly asynchronous,\nconcurrent Python code easier and more Pythonic.\nIt is proposed to make coroutines a proper standalone concept in\nPython, and introduce new supporting syntax. The ultimate goal\nis to help establish a common, easily approachable, mental\nmodel of asynchronous programming in Python and make it as close to\nsynchronous programming as possible.\nThis PEP assumes that the asynchronous tasks are scheduled and\ncoordinated by an Event Loop similar to that of stdlib module\nasyncio.events.AbstractEventLoop. While the PEP is not tied to any\nspecific Event Loop implementation, it is relevant only to the kind of\ncoroutine that uses yield as a signal to the scheduler, indicating\nthat the coroutine will be waiting until an event (such as IO) is\ncompleted.\nWe believe that the changes proposed here will help keep Python\nrelevant and competitive in a quickly growing area of asynchronous\nprogramming, as many other languages have adopted, or are planning to\nadopt, similar features: [2], [5], [6], [7], [8], [10].\n"}, | |
| {"id": "493", "title": "HTTPS verification migration tools for Python 2.7", "authors": "Coghlan, Kuska, Lemburg", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "10-May-2015", "python_version": "2.7.12", "post_history": "06-Jul-2015, 11-Nov-2015, 24-Nov-2015, 24-Feb-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-March/143450.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0493/", "abstract": "\nAbstract\nPEP 476 updated Python's default handling of HTTPS certificates in client\nmodules to align with certificate handling in web browsers, by validating\nthat the certificates received belonged to the server the client was attempting\nto contact. The Python 2.7 long term maintenance series was judged to be in\nscope for this change, with the new behaviour introduced in the Python 2.7.9\nmaintenance release.\nThis has created a non-trivial barrier to adoption for affected Python 2.7\nmaintenance releases, so this PEP proposes additional Python 2.7 specific\nfeatures that allow system administrators and other users to more easily\ndecouple the decision to verify server certificates in HTTPS client modules\nfrom the decision to update to newer Python 2.7 maintenance releases.\n"}, | |
| {"id": "494", "title": "Python 3.6 Release Schedule", "authors": "Deily", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "release", "created": "30-May-2015", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0494/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.6. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "495", "title": "Local Time Disambiguation", "authors": "Belopolsky, Peters", "discussions_to": "datetime-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "02-Aug-2015", "python_version": "3.6", "post_history": null, "resolution": "https://mail.python.org/pipermail/datetime-sig/2015-September/000900.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0495/", "abstract": "\nAbstract\nThis PEP adds a new attribute fold to instances of the\ndatetime.time and datetime.datetime classes that can be used\nto differentiate between two moments in time for which local times are\nthe same. The allowed values for the fold attribute will be 0 and 1\nwith 0 corresponding to the earlier and 1 to the later of the two\npossible readings of an ambiguous local time.\n"}, | |
| {"id": "496", "title": "Environment Markers", "authors": "Polley", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "packaging", "created": "03-Jul-2015", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0496/", "abstract": "\nAbstract\nAn environment marker describes a condition about the current execution\nenvironment. They are used to indicate when certain dependencies are only\nrequired in particular environments, and to indicate supported platforms\nfor distributions with additional constraints beyond the availability of a\nPython runtime.\nEnvironment markers were first specified in PEP 345. PEP 426\n(which would replace PEP 345) proposed extensions to the markers.\nWhen 2.7.10 was released, even these extensions became insufficient due to\ntheir reliance on simple lexical comparisons, and thus this PEP has been born.\n"}, | |
| {"id": "497", "title": "A standard mechanism for backward compatibility", "authors": "Schofield", "discussions_to": null, "status": "Rejected", "type": "Process", "topic": "", "created": "04-Aug-2015", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0497/", "abstract": ""}, | |
| {"id": "498", "title": "Literal String Interpolation", "authors": "Smith", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-Aug-2015", "python_version": "3.6", "post_history": "07-Aug-2015, 30-Aug-2015, 04-Sep-2015, 19-Sep-2015, 06-Nov-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2015-September/141526.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0498/", "abstract": "\nAbstract\nPython supports multiple ways to format text strings. These include\n%-formatting [1], str.format() [2], and string.Template\n[3]. Each of these methods have their advantages, but in addition\nhave disadvantages that make them cumbersome to use in practice. This\nPEP proposed to add a new string formatting mechanism: Literal String\nInterpolation. In this PEP, such strings will be referred to as\n\"f-strings\", taken from the leading character used to denote such\nstrings, and standing for \"formatted strings\".\nThis PEP does not propose to remove or deprecate any of the existing\nstring formatting mechanisms.\nF-strings provide a way to embed expressions inside string literals,\nusing a minimal syntax. It should be noted that an f-string is really\nan expression evaluated at run time, not a constant value. In Python\nsource code, an f-string is a literal string, prefixed with 'f', which\ncontains expressions inside braces. The expressions are replaced with\ntheir values. Some examples are:\n>>> import datetime\n>>> name = 'Fred'\n>>> age = 50\n>>> anniversary = datetime.date(1991, 10, 12)\n>>> f'My name is {name}, my age next year is {age+1}, my anniversary is {anniversary:%A, %B %d, %Y}.'\n'My name is Fred, my age next year is 51, my anniversary is Saturday, October 12, 1991.'\n>>> f'He said his name is {name!r}.'\n\"He said his name is 'Fred'.\"\n\n\nA similar feature was proposed in PEP 215. PEP 215 proposed to support\na subset of Python expressions, and did not support the type-specific\nstring formatting (the __format__() method) which was introduced\nwith PEP 3101.\n"}, | |
| {"id": "499", "title": "``python -m foo`` should bind ``sys.modules['foo']`` in addition to ``sys.modules['__main__']``", "authors": "Simpson, Angelico, Jevnik", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "07-Aug-2015", "python_version": "3.10", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0499/", "abstract": "\nAbstract\nWhen a module is used as a main program on the Python command line,\nsuch as by:\n\npython -m module.name ...\nit is easy to accidentally end up with two independent instances\nof the module if that module is again imported within the program.\nThis PEP proposes a way to fix this problem.\nWhen a module is invoked via Python's -m option the module is bound\nto sys.modules['__main__'] and its .__name__ attribute is set to\n'__main__'.\nThis enables the standard \"main program\" boilerplate code at the\nbottom of many modules, such as:\nif __name__ == '__main__':\n sys.exit(main(sys.argv))\n\n\nHowever, when the above command line invocation is used it is a\nnatural inference to presume that the module is actually imported\nunder its official name module.name,\nand therefore that if the program again imports that name\nthen it will obtain the same module instance.\nThat actuality is that the module was imported only as '__main__'.\nAnother import will obtain a distinct module instance, which can\nlead to confusing bugs,\nall stemming from having two instances of module global objects:\none in each module.\nExamples include:\n\nmodule level data structuresSome modules provide features such as caches or registries\nas module level global variables,\ntypically private.\nA second instance of a module creates a second data structure.\nIf that structure is a cache\nsuch as in the re module\nthen two caches exist leading to wasteful memory use.\nIf that structure is a shared registry\nsuch as a mapping of values to handlers\nthen it is possible to register a handler to one registry\nand to try to use it via the other registry, where it is unknown.\nsentinelsThe standard test for a sentinel value provided by a module\nis the identity comparison using is,\nas this avoids unreliable \"looks like\" comparisons\nsuch as equality which can both mismatch two values as \"equal\"\n(for example being zeroish)\nor raise a TypeError when the objects are incompatible.\nWhen there are two instances of a module\nthere are two sentinel instances\nand only one will be recognised via is.\nclassesWith two modules\nthere are duplicate class definitions of any classes provided.\nAll operations which depend on recognising these classes\nand subclasses of these are prone to failure\ndepending where the reference class\n(from one of the modules) is obtained\nand where the comparison class or instance is obtained.\nThis impacts isinstance, issubclass\nand also try/except constructs.\n\n"}, | |
| {"id": "500", "title": "A protocol for delegating datetime methods to their tzinfo implementations", "authors": "Belopolsky, Peters", "discussions_to": "datetime-sig@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "08-Aug-2015", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/datetime-sig/2015-August/000354.html", "requires": "495", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0500/", "abstract": "\nAbstract\nThis PEP specifies a new protocol (PDDM - \"A Protocol for Delegating\nDatetime Methods\") that can be used by concrete implementations of the\ndatetime.tzinfo interface to override aware datetime arithmetics,\nformatting and parsing. We describe changes to the\ndatetime.datetime class to support the new protocol and propose a\nnew abstract class datetime.tzstrict that implements parts of this\nprotocol necessary to make aware datetime instances to follow \"strict\"\narithmetic rules.\n"}, | |
| {"id": "501", "title": "General purpose string interpolation", "authors": "Coghlan", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "08-Aug-2015", "python_version": "3.6", "post_history": "08-Aug-2015, 23-Aug-2015, 30-Aug-2015", "resolution": null, "requires": "498", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0501/", "abstract": "\nAbstract\nPEP 498 proposes new syntactic support for string interpolation that is\ntransparent to the compiler, allow name references from the interpolation\noperation full access to containing namespaces (as with any other expression),\nrather than being limited to explicit name references. These are referred\nto in the PEP as \"f-strings\" (a mnemonic for \"formatted strings\").\nHowever, it only offers this capability for string formatting, making it likely\nwe will see code like the following:\nos.system(f\"echo {message_from_user}\")\n\n\nThis kind of code is superficially elegant, but poses a significant problem\nif the interpolated value message_from_user is in fact provided by an\nuntrusted user: it's an opening for a form of code injection attack, where\nthe supplied user data has not been properly escaped before being passed to\nthe os.system call.\nTo address that problem (and a number of other concerns), this PEP proposes\nthe complementary introduction of \"i-strings\" (a mnemonic for \"interpolation\ntemplate strings\"), where f\"Message with {data}\" would produce the same\nresult as format(i\"Message with {data}\").\nSome possible examples of the proposed syntax:\nmycommand = sh(i\"cat {filename}\")\nmyquery = sql(i\"SELECT {column} FROM {table};\")\nmyresponse = html(i\"<html><body>{response.body}</body></html>\")\nlogging.debug(i\"Message with {detailed} {debugging} {info}\")\n\n\n"}, | |
| {"id": "502", "title": "String Interpolation - Extended Discussion", "authors": "Miller", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "10-Aug-2015", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0502/", "abstract": "\nAbstract\nPEP 498: Literal String Interpolation, which proposed \"formatted strings\" was\naccepted September 9th, 2015.\nAdditional background and rationale given during its design phase is detailed\nbelow.\nTo recap that PEP,\na string prefix was introduced that marks the string as a template to be\nrendered.\nThese formatted strings may contain one or more expressions\nbuilt on the existing syntax of str.format().\nThe formatted string expands at compile-time into a conventional string format\noperation,\nwith the given expressions from its text extracted and passed instead as\npositional arguments.\nAt runtime,\nthe resulting expressions are evaluated to render a string to given\nspecifications:\n>>> location = 'World'\n>>> f'Hello, {location} !' # new prefix: f''\n'Hello, World !' # interpolated result\n\n\nFormat-strings may be thought of as merely syntactic sugar to simplify traditional\ncalls to str.format().\n"}, | |
| {"id": "503", "title": "Simple Repository API", "authors": "Stufft", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "04-Sep-2015", "python_version": null, "post_history": "04-Sep-2015", "resolution": "https://mail.python.org/pipermail/distutils-sig/2015-September/026899.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0503/", "abstract": "\nAbstract\nThere are many implementations of a Python package repository and many tools\nthat consume them. Of these, the canonical implementation that defines what\nthe \"simple\" repository API looks like is the implementation that powers\nPyPI. This document will specify that API, documenting what the correct\nbehavior for any implementation of the simple repository API.\n"}, | |
| {"id": "504", "title": "Using the System RNG by default", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "15-Sep-2015", "python_version": "3.6", "post_history": "15-Sep-2015", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0504/", "abstract": "\nAbstract\nPython currently defaults to using the deterministic Mersenne Twister random\nnumber generator for the module level APIs in the random module, requiring\nusers to know that when they're performing \"security sensitive\" work, they\nshould instead switch to using the cryptographically secure os.urandom or\nrandom.SystemRandom interfaces or a third party library like\ncryptography.\nUnfortunately, this approach has resulted in a situation where developers that\naren't aware that they're doing security sensitive work use the default module\nlevel APIs, and thus expose their users to unnecessary risks.\nThis isn't an acute problem, but it is a chronic one, and the often long\ndelays between the introduction of security flaws and their exploitation means\nthat it is difficult for developers to naturally learn from experience.\nIn order to provide an eventually pervasive solution to the problem, this PEP\nproposes that Python switch to using the system random number generator by\ndefault in Python 3.6, and require developers to opt-in to using the\ndeterministic random number generator process wide either by using a new\nrandom.ensure_repeatable() API, or by explicitly creating their own\nrandom.Random() instance.\nTo minimise the impact on existing code, module level APIs that require\ndeterminism will implicitly switch to the deterministic PRNG.\n"}, | |
| {"id": "505", "title": "None-aware operators", "authors": "Haase, Dower", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "18-Sep-2015", "python_version": "3.8", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0505/", "abstract": "\nAbstract\nSeveral modern programming languages have so-called \"null-coalescing\" or\n\"null- aware\" operators, including C# [1], Dart [2], Perl, Swift, and PHP\n(starting in version 7). There are also stage 3 draft proposals for their\naddition to ECMAScript (a.k.a. JavaScript) [3] [4]. These operators provide\nsyntactic sugar for common patterns involving null references.\n\nThe \"null-coalescing\" operator is a binary operator that returns its left\noperand if it is not null. Otherwise it returns its right operand.\nThe \"null-aware member access\" operator accesses an instance member only\nif that instance is non-null. Otherwise it returns null. (This is also\ncalled a \"safe navigation\" operator.)\nThe \"null-aware index access\" operator accesses an element of a collection\nonly if that collection is non-null. Otherwise it returns null. (This\nis another type of \"safe navigation\" operator.)\n\nThis PEP proposes three None-aware operators for Python, based on the\ndefinitions and other language's implementations of those above. Specifically:\n\nThe \"None coalescing\" binary operator ?? returns the left hand side\nif it evaluates to a value that is not None, or else it evaluates and\nreturns the right hand side. A coalescing ??= augmented assignment\noperator is included.\nThe \"None-aware attribute access\" operator ?. (\"maybe dot\") evaluates\nthe complete expression if the left hand side evaluates to a value that is\nnot None\nThe \"None-aware indexing\" operator ?[] (\"maybe subscript\") evaluates\nthe complete expression if the left hand site evaluates to a value that is\nnot None\n\nSee the Grammar changes section for specifics and examples of the required\ngrammar changes.\nSee the Examples section for more realistic examples of code that could be\nupdated to use the new operators.\n"}, | |
| {"id": "506", "title": "Adding A Secrets Module To The Standard Library", "authors": "D'Aprano", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Sep-2015", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0506/", "abstract": "\nAbstract\nThis PEP proposes the addition of a module for common security-related\nfunctions such as generating tokens to the Python standard library.\n"}, | |
| {"id": "507", "title": "Migrate CPython to Git and GitLab", "authors": "Warsaw", "discussions_to": null, "status": "Rejected", "type": "Process", "topic": "", "created": "30-Sep-2015", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/core-workflow/2016-January/000345.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0507/", "abstract": "\nAbstract\nThis PEP proposes migrating the repository hosting of CPython and the\nsupporting repositories to Git. Further, it proposes adopting a\nhosted GitLab instance as the primary way of handling merge requests,\ncode reviews, and code hosting. It is similar in intent to PEP 481\nbut proposes an open source alternative to GitHub and omits the\nproposal to run Phabricator. As with PEP 481, this particular PEP is\noffered as an alternative to PEP 474 and PEP 462.\n"}, | |
| {"id": "508", "title": "Dependency specification for Python Software Packages", "authors": "Collins", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "11-Nov-2015", "python_version": null, "post_history": "05-Nov-2015, 16-Nov-2015", "resolution": "https://mail.python.org/pipermail/distutils-sig/2015-November/027868.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0508/", "abstract": "\nAbstract\nThis PEP specifies the language used to describe dependencies for packages.\nIt draws a border at the edge of describing a single dependency - the\ndifferent sorts of dependencies and when they should be installed is a higher\nlevel problem. The intent is to provide a building block for higher layer\nspecifications.\nThe job of a dependency is to enable tools like pip [1] to find the right\npackage to install. Sometimes this is very loose - just specifying a name, and\nsometimes very specific - referring to a specific file to install. Sometimes\ndependencies are only relevant in one platform, or only some versions are\nacceptable, so the language permits describing all these cases.\nThe language defined is a compact line based format which is already in\nwidespread use in pip requirements files, though we do not specify the command\nline option handling that those files permit. There is one caveat - the\nURL reference form, specified in PEP 440 is not actually\nimplemented in pip, but since PEP 440 is accepted, we use that format rather\nthan pip's current native format.\n"}, | |
| {"id": "509", "title": "Add a private version to dict", "authors": "Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "04-Jan-2016", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0509/", "abstract": "\nAbstract\nAdd a new private version to the builtin dict type, incremented at\neach dictionary creation and at each dictionary change, to implement\nfast guards on namespaces.\n"}, | |
| {"id": "510", "title": "Specialize functions with guards", "authors": "Stinner", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "04-Jan-2016", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0510/", "abstract": "\nAbstract\nAdd functions to the Python C API to specialize pure Python functions:\nadd specialized codes with guards. It allows to implement static\noptimizers respecting the Python semantics.\n"}, | |
| {"id": "511", "title": "API for code transformers", "authors": "Stinner", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "04-Jan-2016", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0511/", "abstract": "\nAbstract\nPropose an API to register bytecode and AST transformers. Add also -o\nOPTIM_TAG command line option to change .pyc filenames, -o\nnoopt disables the peephole optimizer. Raise an ImportError\nexception on import if the .pyc file is missing and the code\ntransformers required to transform the code are missing. code\ntransformers are not needed code transformed ahead of time (loaded from\n.pyc files).\n"}, | |
| {"id": "512", "title": "Migrating from hg.python.org to GitHub", "authors": "Cannon", "discussions_to": "core-workflow@python.org", "status": "Final", "type": "Process", "topic": "", "created": "17-Jan-2015", "python_version": null, "post_history": "17-Jan-2016, 19-Jan-2016, 23-Jan-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0512/", "abstract": "\nAbstract\nThis PEP outlines the steps required to migrate Python's development\nprocess from Mercurial [3] as hosted at\nhg.python.org [1] to Git [4] on GitHub [2]. Meeting\nthe minimum goals of this PEP should allow for the development\nprocess of Python to be as productive as it currently is, and meeting\nits extended goals should improve the development process from its\nstatus quo.\n"}, | |
| {"id": "513", "title": "A Platform Tag for Portable Linux Built Distributions", "authors": "McGibbon, Smith", "discussions_to": "distutils-sig@python.org", "status": "Superseded", "type": "Informational", "topic": "packaging", "created": "19-Jan-2016", "python_version": null, "post_history": "19-Jan-2016, 25-Jan-2016, 29-Jan-2016", "resolution": "https://mail.python.org/pipermail/distutils-sig/2016-January/028211.html", "requires": null, "replaces": null, "superseded_by": "600", "url": "https://peps.python.org/pep-0513/", "abstract": "\nAbstract\nThis PEP proposes the creation of a new platform tag for Python package built\ndistributions, such as wheels, called manylinux1_{x86_64,i686} with\nexternal dependencies limited to a standardized, restricted subset of\nthe Linux kernel and core userspace ABI. It proposes that PyPI support\nuploading and distributing wheels with this platform tag, and that pip\nsupport downloading and installing these packages on compatible platforms.\n"}, | |
| {"id": "514", "title": "Python registration in the Windows registry", "authors": "Dower", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "02-Feb-2016", "python_version": null, "post_history": "02-Feb-2016, 01-Mar-2016, 18-Jul-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-July/145697.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0514/", "abstract": "\nAbstract\nThis PEP defines a schema for the Python registry key to allow third-party\ninstallers to register their installation, and to allow tools and applications\nto detect and correctly display all Python environments on a user's machine. No\nimplementation changes to Python are proposed with this PEP.\nPython environments are not required to be registered unless they want to be\nautomatically discoverable by external tools. As this relates to Windows only,\nthese tools are expected to be predominantly GUI applications. However, console\napplications may also make use of the registered information. This PEP covers\nthe information that may be made available, but the actual presentation and use\nof this information is left to the tool designers.\nThe schema matches the registry values that have been used by the official\ninstaller since at least Python 2.5, and the resolution behaviour matches the\nbehaviour of the official Python releases. Some backwards compatibility rules\nare provided to ensure tools can correctly detect versions of CPython that do\nnot register full information.\n"}, | |
| {"id": "515", "title": "Underscores in Numeric Literals", "authors": "Brandl, Storchaka", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "10-Feb-2016", "python_version": "3.6", "post_history": "10-Feb-2016, 11-Feb-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0515/", "abstract": ""}, | |
| {"id": "516", "title": "Build system abstraction for pip/conda etc", "authors": "Collins, Smith", "discussions_to": "distutils-sig@python.org", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "26-Oct-2015", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/distutils-sig/2017-May/030517.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0516/", "abstract": "\nAbstract\nThis PEP specifies a programmatic interface for pip [1] and other\ndistribution or installation tools to use when working with Python\nsource trees (both the developer tree - e.g. the git tree - and source\ndistributions).\nThe programmatic interface allows decoupling of pip from its current\nhard dependency on setuptools [2] able for two\nkey reasons:\n\nIt enables new build systems that may be much easier to use without\nrequiring them to even appear to be setuptools.\nIt facilitates setuptools itself changing its user interface without\nbreaking pip, giving looser coupling.\n\nThe interface needed to permit pip to install build systems also enables pip to\ninstall build time requirements for packages which is an important step in\ngetting pip to full feature parity with the installation components of\neasy-install.\nAs PEP 426 is draft, we cannot utilise the metadata format it\ndefined. However PEP 427 wheels are in wide use and fairly well specified, so\nwe have adopted the METADATA format from that for specifying distribution\ndependencies and general project metadata. PEP 508 provides a\nself-contained language for describing a dependency, which we encapsulate in a\nthin JSON schema to describe bootstrap dependencies.\nSince Python sdists specified in PEP 314 are also source trees, this\nPEP is updating the definition of sdists.\n"}, | |
| {"id": "517", "title": "A build-system independent format for source trees", "authors": "Smith, Kluyver", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "30-Sep-2015", "python_version": null, "post_history": "01-Oct-2015, 25-Oct-2015, 19-May-2017, 11-Sep-2017", "resolution": "https://mail.python.org/pipermail/distutils-sig/2017-September/031548.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0517/", "abstract": "\nAbstract\nWhile distutils / setuptools have taken us a long way, they\nsuffer from three serious problems: (a) they're missing important\nfeatures like usable build-time dependency declaration,\nautoconfiguration, and even basic ergonomic niceties like DRY-compliant\nversion number management, and (b) extending them is difficult, so\nwhile there do exist various solutions to the above problems, they're\noften quirky, fragile, and expensive to maintain, and yet (c) it's\nvery difficult to use anything else, because distutils/setuptools\nprovide the standard interface for installing packages expected by\nboth users and installation tools like pip.\nPrevious efforts (e.g. distutils2 or setuptools itself) have attempted\nto solve problems (a) and/or (b). This proposal aims to solve (c).\nThe goal of this PEP is get distutils-sig out of the business of being\na gatekeeper for Python build systems. If you want to use distutils,\ngreat; if you want to use something else, then that should be easy to\ndo using standardized methods. The difficulty of interfacing with\ndistutils means that there aren't many such systems right now, but to\ngive a sense of what we're thinking about see flit or bento. Fortunately, wheels have now\nsolved many of the hard problems here - e.g. it's no longer necessary\nthat a build system also know about every possible installation\nconfiguration - so pretty much all we really need from a build system\nis that it have some way to spit out standard-compliant wheels and\nsdists.\nWe therefore propose a new, relatively minimal interface for\ninstallation tools like pip to interact with package source trees\nand source distributions.\n"}, | |
| {"id": "518", "title": "Specifying Minimum Build System Requirements for Python Projects", "authors": "Cannon, Smith, Stufft", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "10-May-2016", "python_version": null, "post_history": "10-May-2016, 11-May-2016, 13-May-2016", "resolution": "https://mail.python.org/pipermail/distutils-sig/2016-May/028969.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0518/", "abstract": "\nAbstract\nThis PEP specifies how Python software packages should specify what\nbuild dependencies they have in order to execute their chosen build\nsystem. As part of this specification, a new configuration file is\nintroduced for software packages to use to specify their build\ndependencies (with the expectation that the same configuration file\nwill be used for future configuration details).\n"}, | |
| {"id": "519", "title": "Adding a file system path protocol", "authors": "Cannon, Zevenhoven", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "11-May-2016", "python_version": "3.6", "post_history": "11-May-2016, 12-May-2016, 13-May-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-May/144646.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0519/", "abstract": "\nAbstract\nThis PEP proposes a protocol for classes which represent a file system\npath to be able to provide a str or bytes representation.\nChanges to Python's standard library are also proposed to utilize this\nprotocol where appropriate to facilitate the use of path objects where\nhistorically only str and/or bytes file system paths are\naccepted. The goal is to facilitate the migration of users towards\nrich path objects while providing an easy way to work with code\nexpecting str or bytes.\n"}, | |
| {"id": "520", "title": "Preserving Class Attribute Definition Order", "authors": "Snow", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "07-Jun-2016", "python_version": "3.6", "post_history": "07-Jun-2016, 11-Jun-2016, 20-Jun-2016, 24-Jun-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-June/145442.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0520/", "abstract": "\nAbstract\nThe class definition syntax is ordered by its very nature. Class\nattributes defined there are thus ordered. Aside from helping with\nreadability, that ordering is sometimes significant. If it were\nautomatically available outside the class definition then the\nattribute order could be used without the need for extra boilerplate\n(such as metaclasses or manually enumerating the attribute order).\nGiven that this information already exists, access to the definition\norder of attributes is a reasonable expectation. However, currently\nPython does not preserve the attribute order from the class\ndefinition.\nThis PEP changes that by preserving the order in which attributes\nare introduced in the class definition body. That order will now be\npreserved in the __definition_order__ attribute of the class.\nThis allows introspection of the original definition order, e.g. by\nclass decorators.\nAdditionally, this PEP requires that the default class definition\nnamespace be ordered (e.g. OrderedDict) by default. The long-\nlived class namespace (__dict__) will remain a dict.\n"}, | |
| {"id": "521", "title": "Managing global context via 'with' blocks in generators and coroutines", "authors": "Smith", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "27-Apr-2015", "python_version": "3.6", "post_history": "29-Apr-2015", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0521/", "abstract": "\nAbstract\nWhile we generally try to avoid global state when possible, there\nnonetheless exist a number of situations where it is agreed to be the\nbest approach. In Python, a standard pattern for handling such cases\nis to store the global state in global or thread-local storage, and\nthen use with blocks to limit modifications of this global state\nto a single dynamic scope. Examples where this pattern is used include\nthe standard library's warnings.catch_warnings and\ndecimal.localcontext, NumPy's numpy.errstate (which exposes\nthe error-handling settings provided by the IEEE 754 floating point\nstandard), and the handling of logging context or HTTP request context\nin many server application frameworks.\nHowever, there is currently no ergonomic way to manage such local\nchanges to global state when writing a generator or coroutine. For\nexample, this code:\ndef f():\n with warnings.catch_warnings():\n for x in g():\n yield x\n\n\nmay or may not successfully catch warnings raised by g(), and may\nor may not inadvertently swallow warnings triggered elsewhere in the\ncode. The context manager, which was intended to apply only to f\nand its callees, ends up having a dynamic scope that encompasses\narbitrary and unpredictable parts of its callers. This problem\nbecomes particularly acute when writing asynchronous code, where\nessentially all functions become coroutines.\nHere, we propose to solve this problem by notifying context managers\nwhenever execution is suspended or resumed within their scope,\nallowing them to restrict their effects appropriately.\n"}, | |
| {"id": "522", "title": "Allow BlockingIOError in security sensitive APIs", "authors": "Coghlan, Smith", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "16-Jun-2016", "python_version": "3.6", "post_history": null, "resolution": "https://mail.python.org/pipermail/security-sig/2016-August/000101.html", "requires": "506", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0522/", "abstract": "\nAbstract\nA number of APIs in the standard library that return random values nominally\nsuitable for use in security sensitive operations currently have an obscure\noperating system dependent failure mode that allows them to return values that\nare not, in fact, suitable for such operations.\nThis is due to some operating system kernels (most notably the Linux kernel)\npermitting reads from /dev/urandom before the system random number\ngenerator is fully initialized, whereas most other operating systems will\nimplicitly block on such reads until the random number generator is ready.\nFor the lower level os.urandom and random.SystemRandom APIs, this PEP\nproposes changing such failures in Python 3.6 from the current silent,\nhard to detect, and hard to debug, errors to easily detected and debugged errors\nby raising BlockingIOError with a suitable error message, allowing\ndevelopers the opportunity to unambiguously specify their preferred approach\nfor handling the situation.\nFor the new high level secrets API, it proposes to block implicitly if\nneeded whenever random number is generated by that module, as well as to\nexpose a new secrets.wait_for_system_rng() function to allow code otherwise\nusing the low level APIs to explicitly wait for the system random number\ngenerator to be available.\nThis change will impact any operating system that offers the getrandom()\nsystem call, regardless of whether the default behaviour of the\n/dev/urandom device is to return potentially predictable results when the\nsystem random number generator is not ready (e.g. Linux, NetBSD) or to block\n(e.g. FreeBSD, Solaris, Illumos). Operating systems that prevent execution of\nuserspace code prior to the initialization of the system random number\ngenerator, or do not offer the getrandom() syscall, will be entirely\nunaffected by the proposed change (e.g. Windows, Mac OS X, OpenBSD).\nThe new exception or the blocking behaviour in the secrets module would\npotentially be encountered in the following situations:\n\nPython code calling these APIs during Linux system initialization\nPython code running on improperly initialized Linux systems (e.g. embedded\nhardware without adequate sources of entropy to seed the system random number\ngenerator, or Linux VMs that aren't configured to accept entropy from the\nVM host)\n\n"}, | |
| {"id": "523", "title": "Adding a frame evaluation API to CPython", "authors": "Cannon, Viehland", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-May-2016", "python_version": "3.6", "post_history": "16-May-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-August/145937.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0523/", "abstract": "\nAbstract\nThis PEP proposes to expand CPython's C API [2] to allow for\nthe specification of a per-interpreter function pointer to handle the\nevaluation of frames [5]. This proposal also\nsuggests adding a new field to code objects [3] to store\narbitrary data for use by the frame evaluation function.\n"}, | |
| {"id": "524", "title": "Make os.urandom() blocking on Linux", "authors": "Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "20-Jun-2016", "python_version": "3.6", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0524/", "abstract": "\nAbstract\nModify os.urandom() to block on Linux 3.17 and newer until the OS\nurandom is initialized to increase the security.\nAdd also a new os.getrandom() function (for Linux and Solaris) to be\nable to choose how to handle when os.urandom() is going to block on\nLinux.\n"}, | |
| {"id": "525", "title": "Asynchronous Generators", "authors": "Selivanov", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Jul-2016", "python_version": "3.6", "post_history": "02-Aug-2016, 23-Aug-2016, 01-Sep-2016, 06-Sep-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0525/", "abstract": "\nAbstract\nPEP 492 introduced support for native coroutines and async/await\nsyntax to Python 3.5. It is proposed here to extend Python's\nasynchronous capabilities by adding support for\nasynchronous generators.\n"}, | |
| {"id": "526", "title": "Syntax for Variable Annotations", "authors": "Gonzalez, House, Levkivskyi, Roach, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "typing", "created": "09-Aug-2016", "python_version": "3.6", "post_history": "30-Aug-2016, 02-Sep-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-September/146282.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0526/", "abstract": "\nAbstract\nPEP 484 introduced type hints, a.k.a. type annotations. While its\nmain focus was function annotations, it also introduced the notion of\ntype comments to annotate variables:\n# 'primes' is a list of integers\nprimes = [] # type: List[int]\n\n# 'captain' is a string (Note: initial value is a problem)\ncaptain = ... # type: str\n\nclass Starship:\n # 'stats' is a class variable\n stats = {} # type: Dict[str, int]\n\n\nThis PEP aims at adding syntax to Python for annotating the types of variables\n(including class variables and instance variables),\ninstead of expressing them through comments:\nprimes: List[int] = []\n\ncaptain: str # Note: no initial value!\n\nclass Starship:\n stats: ClassVar[Dict[str, int]] = {}\n\n\nPEP 484 explicitly states that type comments are intended to help with\ntype inference in complex cases, and this PEP does not change this\nintention. However, since in practice type comments have also been\nadopted for class variables and instance variables, this PEP also\ndiscusses the use of type annotations for those variables.\n"}, | |
| {"id": "527", "title": "Removing Un(der)used file types/extensions on PyPI", "authors": "Stufft", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Process", "topic": "packaging", "created": "23-Aug-2016", "python_version": null, "post_history": "23-Aug-2016", "resolution": "https://mail.python.org/pipermail/distutils-sig/2016-September/029624.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0527/", "abstract": "\nAbstract\nThis PEP recommends deprecating, and ultimately removing, support for uploading\ncertain unused or under used file types and extensions to PyPI. In particular\nit recommends disallowing further uploads of any files of the types\nbdist_dumb, bdist_rpm, bdist_dmg, bdist_msi, and\nbdist_wininst, leaving PyPI to only accept new uploads of the sdist,\nbdist_wheel, and bdist_egg file types.\nIn addition, this PEP proposes removing support for new uploads of sdists using\nthe .tar, .tar.bz2, .tar.xz, .tar.Z, .tgz, .tbz, and\nany other extension besides .tar.gz and .zip.\nFinally, this PEP also proposes limiting the number of allowed sdist uploads\nfor each individual release of a project on PyPI to one instead of one for each\nallowed extension.\n"}, | |
| {"id": "528", "title": "Change Windows console encoding to UTF-8", "authors": "Dower", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Aug-2016", "python_version": "3.6", "post_history": "01-Sep-2016, 04-Sep-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-September/146278.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0528/", "abstract": "\nAbstract\nHistorically, Python uses the ANSI APIs for interacting with the Windows\noperating system, often via C Runtime functions. However, these have been long\ndiscouraged in favor of the UTF-16 APIs. Within the operating system, all text\nis represented as UTF-16, and the ANSI APIs perform encoding and decoding using\nthe active code page.\nThis PEP proposes changing the default standard stream implementation on Windows\nto use the Unicode APIs. This will allow users to print and input the full range\nof Unicode characters at the default Windows console. This also requires a\nsubtle change to how the tokenizer parses text from readline hooks.\n"}, | |
| {"id": "529", "title": "Change Windows filesystem encoding to UTF-8", "authors": "Dower", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Aug-2016", "python_version": "3.6", "post_history": "01-Sep-2016, 04-Sep-2016", "resolution": "https://mail.python.org/pipermail/python-dev/2016-September/146277.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0529/", "abstract": "\nAbstract\nHistorically, Python uses the ANSI APIs for interacting with the Windows\noperating system, often via C Runtime functions. However, these have been long\ndiscouraged in favor of the UTF-16 APIs. Within the operating system, all text\nis represented as UTF-16, and the ANSI APIs perform encoding and decoding using\nthe active code page. See Naming Files, Paths, and Namespaces for\nmore details.\nThis PEP proposes changing the default filesystem encoding on Windows to utf-8,\nand changing all filesystem functions to use the Unicode APIs for filesystem\npaths. This will not affect code that uses strings to represent paths, however\nthose that use bytes for paths will now be able to correctly round-trip all\nvalid paths in Windows filesystems. Currently, the conversions between Unicode\n(in the OS) and bytes (in Python) were lossy and would fail to round-trip\ncharacters outside of the user's active code page.\nNotably, this does not impact the encoding of the contents of files. These will\ncontinue to default to locale.getpreferredencoding() (for text files) or\nplain bytes (for binary files). This only affects the encoding used when users\npass a bytes object to Python where it is then passed to the operating system as\na path name.\n"}, | |
| {"id": "530", "title": "Asynchronous Comprehensions", "authors": "Selivanov", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "03-Sep-2016", "python_version": "3.6", "post_history": "03-Sep-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0530/", "abstract": "\nAbstract\nPEP 492 and PEP 525 introduce support for native coroutines and\nasynchronous generators using async / await syntax. This PEP\nproposes to add asynchronous versions of list, set, dict comprehensions\nand generator expressions.\n"}, | |
| {"id": "531", "title": "Existence checking operators", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "25-Oct-2016", "python_version": "3.7", "post_history": "28-Oct-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0531/", "abstract": "\nAbstract\nInspired by PEP 505 and the related discussions, this PEP proposes the addition\nof two new control flow operators to Python:\n\nExistence-checking precondition (\"exists-then\"): expr1 ?then expr2\nExistence-checking fallback (\"exists-else\"): expr1 ?else expr2\n\nas well as the following abbreviations for common existence checking\nexpressions and statements:\n\nExistence-checking attribute access:\nobj?.attr (for obj ?then obj.attr)\nExistence-checking subscripting:\nobj?[expr] (for obj ?then obj[expr])\nExistence-checking assignment:\nvalue ?= expr (for value = value ?else expr)\n\nThe common ? symbol in these new operator definitions indicates that they\nuse a new \"existence checking\" protocol rather than the established\ntruth-checking protocol used by if statements, while loops, comprehensions,\ngenerator expressions, conditional expressions, logical conjunction, and\nlogical disjunction.\nThis new protocol would be made available as operator.exists, with the\nfollowing characteristics:\n\ntypes can define a new __exists__ magic method (Python) or\ntp_exists slot (C) to override the default behaviour. This optional\nmethod has the same signature and possible return values as __bool__.\noperator.exists(None) returns False\noperator.exists(NotImplemented) returns False\noperator.exists(Ellipsis) returns False\nfloat, complex and decimal.Decimal will override the existence\ncheck such that NaN values return False and other values (including\nzero values) return True\nfor any other type, operator.exists(obj) returns True by default. Most\nimportantly, values that evaluate to False in a truth checking context\n(zeroes, empty containers) will still evaluate to True in an existence\nchecking context\n\n"}, | |
| {"id": "532", "title": "A circuit breaking protocol and binary operators", "authors": "Coghlan, Haase", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "30-Oct-2016", "python_version": "3.8", "post_history": "05-Nov-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0532/", "abstract": "\nAbstract\nInspired by PEP 335, PEP 505, PEP 531, and the related discussions, this PEP\nproposes the definition of a new circuit breaking protocol (using the\nmethod names __then__ and __else__) that provides a common underlying\nsemantic foundation for:\n\nconditional expressions: LHS if COND else RHS\nlogical conjunction: LHS and RHS\nlogical disjunction: LHS or RHS\nthe None-aware operators proposed in PEP 505\nthe rich comparison chaining model proposed in PEP 535\n\nTaking advantage of the new protocol, it further proposes that the definition\nof conditional expressions be revised to also permit the use of if and\nelse respectively as right-associative and left-associative general\npurpose short-circuiting operators:\n\nRight-associative short-circuiting: LHS if RHS\nLeft-associative short-circuiting: LHS else RHS\n\nIn order to make logical inversion (not EXPR) consistent with the above\nchanges, it also proposes the introduction of a new logical inversion protocol\n(using the method name __not__).\nTo force short-circuiting of a circuit breaker without having to evaluate\nthe expression creating it twice, a new operator.short_circuit(obj)\nhelper function will be added to the operator module.\nFinally, a new standard types.CircuitBreaker type is proposed to decouple\nan object's truth value (as used to determine control flow) from the value\nit returns from short-circuited circuit breaking expressions, with the\nfollowing factory functions added to the operator module to represent\nparticularly common switching idioms:\n\nswitching on bool(obj): operator.true(obj)\nswitching on not bool(obj): operator.false(obj)\nswitching on obj is value: operator.is_sentinel(obj, value)\nswitching on obj is not value: operator.is_not_sentinel(obj, value)\n\n"}, | |
| {"id": "533", "title": "Deterministic cleanup for iterators", "authors": "Smith", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "18-Oct-2016", "python_version": null, "post_history": "18-Oct-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0533/", "abstract": "\nAbstract\nWe propose to extend the iterator protocol with a new\n__(a)iterclose__ slot, which is called automatically on exit from\n(async) for loops, regardless of how they exit. This allows for\nconvenient, deterministic cleanup of resources held by iterators\nwithout reliance on the garbage collector. This is especially valuable\nfor asynchronous generators.\n"}, | |
| {"id": "534", "title": "Improved Errors for Missing Standard Library Modules", "authors": "Orsava, Viktorin, Coghlan", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "05-Sep-2016", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0534/", "abstract": "\nAbstract\nPython is often being built or distributed without its full standard library.\nHowever, there is as of yet no standard, user friendly way of properly\ninforming the user about the failure to import such missing standard library\nmodules.\nThis PEP proposes a mechanism for identifying expected standard library modules\nand providing more informative error messages to users when attempts to import\nstandard library modules fail.\n"}, | |
| {"id": "535", "title": "Rich comparison chaining", "authors": "Coghlan", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "12-Nov-2016", "python_version": "3.8", "post_history": null, "resolution": null, "requires": "532", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0535/", "abstract": "\nAbstract\nInspired by PEP 335, and building on the circuit breaking protocol described\nin PEP 532, this PEP proposes a change to the definition of chained comparisons,\nwhere the comparison chaining will be updated to use the left-associative\ncircuit breaking operator (else) rather than the logical disjunction\noperator (and) if the left hand comparison returns a circuit breaker as\nits result.\nWhile there are some practical complexities arising from the current handling\nof single-valued arrays in NumPy, this change should be sufficient to allow\nelementwise chained comparison operations for matrices, where the result\nis a matrix of boolean values, rather than raising ValueError\nor tautologically returning True (indicating a non-empty matrix).\n"}, | |
| {"id": "536", "title": "Final Grammar for Literal String Interpolation", "authors": "Angerer", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "11-Dec-2016", "python_version": "3.7", "post_history": "12-Dec-2016", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0536/", "abstract": "\nAbstract\nPEP 498 introduced Literal String Interpolation (or \"f-strings\").\nThe expression portions of those literals however are subject to\ncertain restrictions. This PEP proposes a formal grammar lifting\nthose restrictions, promoting \"f-strings\" to \"f expressions\" or f-literals.\nThis PEP expands upon the f-strings introduced by PEP 498,\nso this text requires familiarity with PEP 498.\n"}, | |
| {"id": "537", "title": "Python 3.7 Release Schedule", "authors": "Deily", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "release", "created": "23-Dec-2016", "python_version": "3.7", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0537/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.7. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "538", "title": "Coercing the legacy C locale to a UTF-8 based locale", "authors": "Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Dec-2016", "python_version": "3.7", "post_history": "03-Jan-2017, 07-Jan-2017, 05-Mar-2017, 09-May-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-May/148035.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0538/", "abstract": "\nAbstract\nAn ongoing challenge with Python 3 on *nix systems is the conflict between\nneeding to use the configured locale encoding by default for consistency with\nother locale-aware components in the same process or subprocesses,\nand the fact that the standard C locale (as defined in POSIX:2001) typically\nimplies a default text encoding of ASCII, which is entirely inadequate for the\ndevelopment of networked services and client applications in a multilingual\nworld.\nPEP 540 proposes a change to CPython's handling of the legacy C locale such\nthat CPython will assume the use of UTF-8 in such environments, rather than\npersisting with the demonstrably problematic assumption of ASCII as an\nappropriate encoding for communicating with operating system interfaces.\nThis is a good approach for cases where network encoding interoperability\nis a more important concern than local encoding interoperability.\nHowever, it comes at the cost of making CPython's encoding assumptions diverge\nfrom those of other locale-aware components in the same process, as well as\nthose of components running in subprocesses that share the same environment.\nThis can cause interoperability problems with some extension modules (such as\nGNU readline's command line history editing), as well as with components\nrunning in subprocesses (such as older Python runtimes).\nIt also requires non-trivial changes to the internals of how CPython itself\nworks, rather than relying primarily on existing configuration settings that\nare supported by Python versions prior to Python 3.7.\nAccordingly, this PEP proposes that independently of the UTF-8 mode proposed\nin PEP 540, the way the CPython implementation handles the default C locale be\nchanged to be roughly equivalent to the following existing configuration\nsettings (supported since Python 3.1):\nLC_CTYPE=C.UTF-8\nPYTHONIOENCODING=utf-8:surrogateescape\n\n\nThe exact target locale for coercion will be chosen from a predefined list at\nruntime based on the actually available locales.\nThe reinterpreted locale settings will be written back to the environment so\nthey're visible to other components in the same process and in subprocesses,\nbut the changed PYTHONIOENCODING default will be made implicit in order to\navoid causing compatibility problems with Python 2 subprocesses that don't\nprovide the surrogateescape error handler.\nThe new legacy locale coercion behavior can be disabled either by setting\nLC_ALL (which may still lead to a Unicode compatibility warning) or by\nsetting the new PYTHONCOERCECLOCALE environment variable to 0.\nWith this change, any *nix platform that does not offer at least one of the\nC.UTF-8, C.utf8 or UTF-8 locales as part of its standard\nconfiguration would only be considered a fully supported platform for CPython\n3.7+ deployments when a suitable locale other than the default C locale is\nconfigured explicitly (e.g. en_AU.UTF-8, zh_CN.gb18030). If PEP 540 is\naccepted in addition to this PEP, then pure Python modules would also be\nsupported when using the proposed PYTHONUTF8 mode, but expectations for\nfull Unicode compatibility in extension modules would continue to be limited\nto the platforms covered by this PEP.\nAs it only reflects a change in default settings rather than a fundamentally\nnew capability, redistributors (such as Linux distributions) with a narrower\ntarget audience than the upstream CPython development team may also choose to\nopt in to this locale coercion behaviour for the Python 3.6.x series by\napplying the necessary changes as a downstream patch.\n"}, | |
| {"id": "539", "title": "A New C-API for Thread-Local Storage in CPython", "authors": "Bray, Yamamoto", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "20-Dec-2016", "python_version": "3.7", "post_history": "16-Dec-2016, 31-Aug-2017, 08-Sep-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-September/149358.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0539/", "abstract": "\nAbstract\nThe proposal is to add a new Thread Local Storage (TLS) API to CPython which\nwould supersede use of the existing TLS API within the CPython interpreter,\nwhile deprecating the existing API. The new API is named the \"Thread\nSpecific Storage (TSS) API\" (see Rationale for Proposed Solution for the\norigin of the name).\nBecause the existing TLS API is only used internally (it is not mentioned in\nthe documentation, and the header that defines it, pythread.h, is not\nincluded in Python.h either directly or indirectly), this proposal\nprobably only affects CPython, but might also affect other interpreter\nimplementations (PyPy?) that implement parts of the CPython API.\nThis is motivated primarily by the fact that the old API uses int to\nrepresent TLS keys across all platforms, which is neither POSIX-compliant,\nnor portable in any practical sense [1].\n\nNote\nThroughout this document the acronym \"TLS\" refers to Thread Local\nStorage and should not be confused with \"Transportation Layer Security\"\nprotocols.\n\n"}, | |
| {"id": "540", "title": "Add a new UTF-8 Mode", "authors": "Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Jan-2016", "python_version": "3.7", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2017-December/151173.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0540/", "abstract": "\nAbstract\nAdd a new \"UTF-8 Mode\" to enhance Python's use of UTF-8. When UTF-8 Mode\nis active, Python will:\n\nuse the utf-8 encoding, regardless of the locale currently set by\nthe current platform, and\nchange the stdin and stdout error handlers to\nsurrogateescape.\n\nThis mode is off by default, but is automatically activated when using\nthe \"POSIX\" locale.\nAdd the -X utf8 command line option and PYTHONUTF8 environment\nvariable to control UTF-8 Mode.\n"}, | |
| {"id": "541", "title": "Package Index Name Retention", "authors": "Langa", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Process", "topic": "packaging", "created": "12-Jan-2017", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/distutils-sig/2018-March/032089.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0541/", "abstract": "\nAbstract\nThis PEP proposes an extension to the Terms of Use [1] of the Package\nIndex [2], clarifying expectations of package owners regarding\nownership of a package name on the Package Index, specifically with\nregards to conflict resolution.\nExisting package repositories such as CPAN [3], NPM [4], and\nGitHub [5] will be investigated as prior art in this field.\n"}, | |
| {"id": "542", "title": "Dot Notation Assignment In Function Header", "authors": "Meskanen", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "10-Feb-2017", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2019-March/156695.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0542/", "abstract": "\nAbstract\nFunction definitions only allow simple function names to be used,\neven though functions are assignable first class objects.\nThis PEP proposes adding support for assigning a function to\na class or instance attribute directly in the function\ndefinition's header by using the dot notation to separate\nthe object from the function's name.\nAlthough a similar feature, this PEP does not address general\nassignment to anything that supports assignment, such as dict keys\nand list indexes.\n"}, | |
| {"id": "543", "title": "A Unified TLS API for Python", "authors": "Benfield, Heimes", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "17-Oct-2016", "python_version": "3.7", "post_history": "11-Jan-2017, 19-Jan-2017, 02-Feb-2017, 09-Feb-2017", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0543/", "abstract": "\nAbstract\nThis PEP would define a standard TLS interface in the form of a collection of\nabstract base classes. This interface would allow Python implementations and\nthird-party libraries to provide bindings to TLS libraries other than OpenSSL\nthat can be used by tools that expect the interface provided by the Python\nstandard library, with the goal of reducing the dependence of the Python\necosystem on OpenSSL.\n"}, | |
| {"id": "544", "title": "Protocols: Structural subtyping (static duck typing)", "authors": "Levkivskyi, Lehtosalo, Langa", "discussions_to": "python-dev@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "05-Mar-2017", "python_version": "3.8", "post_history": null, "resolution": "https://mail.python.org/archives/list/typing-sig@python.org/message/FDO4KFYWYQEP3U2HVVBEBR3SXPHQSHYR/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0544/", "abstract": "\nAbstract\nType hints introduced in PEP 484 can be used to specify type metadata\nfor static type checkers and other third party tools. However, PEP 484\nonly specifies the semantics of nominal subtyping. In this PEP we specify\nstatic and runtime semantics of protocol classes that will provide a support\nfor structural subtyping (static duck typing).\n"}, | |
| {"id": "545", "title": "Python Documentation Translations", "authors": "Palard, Inada, Stinner", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "04-Mar-2017", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2017-May/147957.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0545/", "abstract": "\nAbstract\nThe intent of this PEP is to make existing translations of the Python\nDocumentation more accessible and discoverable. By doing so, we hope\nto attract and motivate new translators and new translations.\nTranslated documentation will be hosted on python.org. Examples of\ntwo active translation teams:\n\nhttp://docs.python.org/fr/: French\nhttp://docs.python.org/ja/: Japanese\n\nhttp://docs.python.org/en/ will redirect to http://docs.python.org/.\nSources of translated documentation will be hosted in the Python\norganization on GitHub: https://github.com/python/. Contributors will\nhave to accept a Documentation Contribution Agreement.\n"}, | |
| {"id": "546", "title": "Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7", "authors": "Stinner, Benfield", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "30-May-2017", "python_version": "2.7", "post_history": "23-May-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-June/148301.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0546/", "abstract": "\nAbstract\nBackport the ssl.MemoryBIO and ssl.SSLObject classes from Python 3 to Python\n2.7 to enhance the overall security of Python 2.7.\n"}, | |
| {"id": "547", "title": "Running extension modules using the -m option", "authors": "Plch, Viktorin", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "25-May-2017", "python_version": "3.7", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0547/", "abstract": "\nAbstract\nThis PEP proposes implementation that allows built-in and extension\nmodules to be executed in the __main__ namespace using\nthe PEP 489 multi-phase initialization.\nWith this, a multi-phase initialization enabled module can be run\nusing following command:\n$ python3 -m _testmultiphase\nThis is a test module named __main__.\n\n\n"}, | |
| {"id": "548", "title": "More Flexible Loop Control", "authors": "Murray", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "05-Sep-2017", "python_version": "3.7", "post_history": "05-Aug-2017", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0548/", "abstract": "\nAbstract\nThis PEP proposes enhancing the break and continue statements\nwith an optional boolean expression that controls whether or not\nthey execute. This allows the flow of control in loops to be\nexpressed more clearly and compactly.\n"}, | |
| {"id": "549", "title": "Instance Descriptors", "authors": "Hastings", "discussions_to": "python-dev@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "04-Sep-2017", "python_version": "3.7", "post_history": "04-Sep-2017", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0549/", "abstract": "\nAbstract\nPython's descriptor protocol requires that descriptors\nbe members of the type of an object. This PEP proposes\nan extension to the descriptor protocol allowing use of\nthe descriptor protocol for members of instances. This\nwould permit using properties in modules.\n"}, | |
| {"id": "550", "title": "Execution Context", "authors": "Selivanov, Pranskevichus", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "11-Aug-2017", "python_version": "3.7", "post_history": "11-Aug-2017, 15-Aug-2017, 18-Aug-2017, 25-Aug-2017, 01-Sep-2017", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0550/", "abstract": "\nAbstract\nThis PEP adds a new generic mechanism of ensuring consistent access\nto non-local state in the context of out-of-order execution, such\nas in Python generators and coroutines.\nThread-local storage, such as threading.local(), is inadequate for\nprograms that execute concurrently in the same OS thread. This PEP\nproposes a solution to this problem.\n"}, | |
| {"id": "551", "title": "Security transparency in the Python runtime", "authors": "Dower", "discussions_to": null, "status": "Withdrawn", "type": "Informational", "topic": "", "created": "23-Aug-2017", "python_version": "3.7", "post_history": "24-Aug-2017, 28-Aug-2017", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0551/", "abstract": "\nAbstract\nThis PEP describes the concept of security transparency and how it\napplies to the Python runtime. Visibility into actions taken by the\nruntime is invaluable in integrating Python into an otherwise secure\nand/or monitored environment.\nThe audit hooks described in PEP 578 are an essential component in\ndetecting, identifying and analyzing misuse of Python. While the hooks\nthemselves are neutral (in that not every reported event is inherently\nmisuse), they provide essential context to those who are responsible\nfor monitoring an overall system or network. With enough transparency,\nattackers are no longer able to hide.\n"}, | |
| {"id": "552", "title": "Deterministic pycs", "authors": "Peterson", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "04-Sep-2017", "python_version": "3.7", "post_history": "07-Sep-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-September/149649.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0552/", "abstract": "\nAbstract\nThis PEP proposes an extension to the pyc format to make it more deterministic.\n"}, | |
| {"id": "553", "title": "Built-in breakpoint()", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Sep-2017", "python_version": "3.7", "post_history": "05-Sep-2017, 07-Sep-2017, 13-Sep-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-October/149705.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0553/", "abstract": "\nAbstract\nThis PEP proposes adding a new built-in function called breakpoint() which\nenters a Python debugger at the point of the call. Additionally, two new\nnames are added to the sys module to make the choice of which debugger is\nentered configurable.\n"}, | |
| {"id": "554", "title": "Multiple Interpreters in the Stdlib", "authors": "Snow", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "", "created": "05-Sep-2017", "python_version": "3.12", "post_history": "07-Sep-2017, 08-Sep-2017, 13-Sep-2017, 05-Dec-2017, 09-May-2018, 20-Apr-2020, 04-May-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0554/", "abstract": "\nAbstract\nCPython has supported multiple interpreters in the same process (AKA\n\"subinterpreters\") since version 1.5 (1997). The feature has been\navailable via the C-API. [c-api] Subinterpreters operate in\nrelative isolation from one another, which\nfacilitates novel alternative approaches to\nconcurrency.\nThis proposal introduces the stdlib interpreters module. The module\nwill be provisional. It exposes the basic\nfunctionality of subinterpreters already provided by the C-API, along\nwith new (basic) functionality for sharing data between interpreters.\n"}, | |
| {"id": "555", "title": "Context-local variables (contextvars)", "authors": "Zevenhoven", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "06-Sep-2017", "python_version": "3.7", "post_history": "06-Sep-2017", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0555/", "abstract": "\nAbstract\nSometimes, in special cases, it is desired that code can pass information down the function call chain to the callees without having to explicitly pass the information as arguments to each function in the call chain. This proposal describes a construct which allows code to explicitly switch in and out of a context where a certain context variable has a given value assigned to it. This is a modern alternative to some uses of things like global variables in traditional single-threaded (or thread-unsafe) code and of thread-local storage in traditional concurrency-unsafe code (single- or multi-threaded). In particular, the proposed mechanism can also be used with more modern concurrent execution mechanisms such as asynchronously executed coroutines, without the concurrently executed call chains interfering with each other's contexts.\nThe \"call chain\" can consist of normal functions, awaited coroutines, or generators. The semantics of context variable scope are equivalent in all cases, allowing code to be refactored freely into subroutines (which here refers to functions, sub-generators or sub-coroutines) without affecting the semantics of context variables. Regarding implementation, this proposal aims at simplicity and minimum changes to the CPython interpreter and to other Python interpreters.\n"}, | |
| {"id": "556", "title": "Threaded garbage collection", "authors": "Pitrou", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "08-Sep-2017", "python_version": "3.7", "post_history": "08-Sep-2017", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0556/", "abstract": "\nAbstract\nThis PEP proposes a new optional mode of operation for CPython's cyclic\ngarbage collector (GC) where implicit (i.e. opportunistic) collections\nhappen in a dedicated thread rather than synchronously.\n"}, | |
| {"id": "557", "title": "Data Classes", "authors": "Smith", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "02-Jun-2017", "python_version": "3.7", "post_history": "08-Sep-2017, 25-Nov-2017, 30-Nov-2017, 01-Dec-2017, 02-Dec-2017, 06-Jan-2018, 04-Mar-2018", "resolution": "https://mail.python.org/pipermail/python-dev/2017-December/151034.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0557/", "abstract": "\nAbstract\nThis PEP describes an addition to the standard library called Data\nClasses. Although they use a very different mechanism, Data Classes\ncan be thought of as \"mutable namedtuples with defaults\". Because\nData Classes use normal class definition syntax, you are free to use\ninheritance, metaclasses, docstrings, user-defined methods, class\nfactories, and other Python class features.\nA class decorator is provided which inspects a class definition for\nvariables with type annotations as defined in PEP 526, \"Syntax for\nVariable Annotations\". In this document, such variables are called\nfields. Using these fields, the decorator adds generated method\ndefinitions to the class to support instance initialization, a repr,\ncomparison methods, and optionally other methods as described in the\nSpecification section. Such a class is called a Data Class, but\nthere's really nothing special about the class: the decorator adds\ngenerated methods to the class and returns the same class it was\ngiven.\nAs an example:\n@dataclass\nclass InventoryItem:\n '''Class for keeping track of an item in inventory.'''\n name: str\n unit_price: float\n quantity_on_hand: int = 0\n\n def total_cost(self) -> float:\n return self.unit_price * self.quantity_on_hand\n\n\nThe @dataclass decorator will add the equivalent of these methods\nto the InventoryItem class:\ndef __init__(self, name: str, unit_price: float, quantity_on_hand: int = 0) -> None:\n self.name = name\n self.unit_price = unit_price\n self.quantity_on_hand = quantity_on_hand\ndef __repr__(self):\n return f'InventoryItem(name={self.name!r}, unit_price={self.unit_price!r}, quantity_on_hand={self.quantity_on_hand!r})'\ndef __eq__(self, other):\n if other.__class__ is self.__class__:\n return (self.name, self.unit_price, self.quantity_on_hand) == (other.name, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __ne__(self, other):\n if other.__class__ is self.__class__:\n return (self.name, self.unit_price, self.quantity_on_hand) != (other.name, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __lt__(self, other):\n if other.__class__ is self.__class__:\n return (self.name, self.unit_price, self.quantity_on_hand) < (other.name, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __le__(self, other):\n if other.__class__ is self.__class__:\n return (self.name, self.unit_price, self.quantity_on_hand) <= (other.name, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __gt__(self, other):\n if other.__class__ is self.__class__:\n return (self.name, self.unit_price, self.quantity_on_hand) > (other.name, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __ge__(self, other):\n if other.__class__ is self.__class__:\n return (self.name, self.unit_price, self.quantity_on_hand) >= (other.name, other.unit_price, other.quantity_on_hand)\n return NotImplemented\n\n\nData Classes save you from writing and maintaining these methods.\n"}, | |
| {"id": "558", "title": "Defined semantics for locals()", "authors": "Coghlan", "discussions_to": "python-dev@python.org", "status": "Draft", "type": "Standards Track", "topic": "", "created": "08-Sep-2017", "python_version": "3.12", "post_history": "08-Sep-2017, 22-May-2019, 30-May-2019, 30-Dec-2019, 18-Jul-2021, 26-Aug-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0558/", "abstract": "\nAbstract\nThe semantics of the locals() builtin have historically been underspecified\nand hence implementation dependent.\nThis PEP proposes formally standardising on the behaviour of the CPython 3.10\nreference implementation for most execution scopes, with some adjustments to the\nbehaviour at function scope to make it more predictable and independent of the\npresence or absence of tracing functions.\nIn addition, it proposes that the following functions be added to the stable\nPython C API/ABI:\ntypedef enum {\n PyLocals_UNDEFINED = -1,\n PyLocals_DIRECT_REFERENCE = 0,\n PyLocals_SHALLOW_COPY = 1,\n _PyLocals_ENSURE_32BIT_ENUM = 2147483647\n} PyLocals_Kind;\n\nPyLocals_Kind PyLocals_GetKind();\nPyObject * PyLocals_Get();\nPyObject * PyLocals_GetCopy();\n\n\nIt also proposes the addition of several supporting functions and type\ndefinitions to the CPython C API.\n"}, | |
| {"id": "559", "title": "Built-in noop()", "authors": "Warsaw", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "08-Sep-2017", "python_version": "3.7", "post_history": "09-Sep-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-September/149438.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0559/", "abstract": "\nAbstract\nThis PEP proposes adding a new built-in function called noop() which does\nnothing but return None.\n"}, | |
| {"id": "560", "title": "Core support for typing module and generic types", "authors": "Levkivskyi", "discussions_to": null, "status": "Accepted", "type": "Standards Track", "topic": "", "created": "03-Sep-2017", "python_version": "3.7", "post_history": "09-Sep-2017, 14-Nov-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-December/151038.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0560/", "abstract": "\nAbstract\nInitially PEP 484 was designed in such way that it would not introduce\nany changes to the core CPython interpreter. Now type hints and\nthe typing module are extensively used by the community, e.g. PEP 526\nand PEP 557 extend the usage of type hints, and the backport of typing\non PyPI has 1M downloads/month. Therefore, this restriction can be removed.\nIt is proposed to add two special methods __class_getitem__ and\n__mro_entries__ to the core CPython for better support of\ngeneric types.\n"}, | |
| {"id": "561", "title": "Distributing and Packaging Type Information", "authors": "Smith", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "packaging, typing", "created": "09-Sep-2017", "python_version": "3.7", "post_history": "10-Sep-2017, 12-Sep-2017, 06-Oct-2017, 26-Oct-2017, 12-Apr-2018", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0561/", "abstract": "\nAbstract\nPEP 484 introduced type hinting to Python, with goals of making typing\ngradual and easy to adopt. Currently, typing information must be distributed\nmanually. This PEP provides a standardized means to leverage existing tooling\nto package and distribute type information with minimal work and an ordering\nfor type checkers to resolve modules and collect this information for type\nchecking.\n"}, | |
| {"id": "562", "title": "Module __getattr__ and __dir__", "authors": "Levkivskyi", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "09-Sep-2017", "python_version": "3.7", "post_history": "09-Sep-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-December/151033.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0562/", "abstract": "\nAbstract\nIt is proposed to support __getattr__ and __dir__ function defined\non modules to provide basic customization of module attribute access.\n"}, | |
| {"id": "563", "title": "Postponed Evaluation of Annotations", "authors": "Langa", "discussions_to": "python-dev@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "08-Sep-2017", "python_version": "3.7", "post_history": "01-Nov-2017, 21-Nov-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-December/151042.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0563/", "abstract": "\nAbstract\nPEP 3107 introduced syntax for function annotations, but the semantics\nwere deliberately left undefined. PEP 484 introduced a standard meaning\nto annotations: type hints. PEP 526 defined variable annotations,\nexplicitly tying them with the type hinting use case.\nThis PEP proposes changing function annotations and variable annotations\nso that they are no longer evaluated at function definition time.\nInstead, they are preserved in __annotations__ in string form.\nThis change is being introduced gradually, starting with a\n__future__ import in Python 3.7.\n"}, | |
| {"id": "564", "title": "Add new time functions with nanosecond resolution", "authors": "Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-Oct-2017", "python_version": "3.7", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2017-October/150046.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0564/", "abstract": "\nAbstract\nAdd six new \"nanosecond\" variants of existing functions to the time\nmodule: clock_gettime_ns(), clock_settime_ns(),\nmonotonic_ns(), perf_counter_ns(), process_time_ns() and\ntime_ns(). While similar to the existing functions without the\n_ns suffix, they provide nanosecond resolution: they return a number of\nnanoseconds as a Python int.\nThe time.time_ns() resolution is 3 times better than the time.time()\nresolution on Linux and Windows.\n"}, | |
| {"id": "565", "title": "Show DeprecationWarning in __main__", "authors": "Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "12-Nov-2017", "python_version": "3.7", "post_history": "12-Nov-2017, 25-Nov-2017", "resolution": "https://mail.python.org/pipermail/python-dev/2017-December/151224.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0565/", "abstract": "\nAbstract\nIn Python 2.7 and Python 3.2, the default warning filters were updated to hide\nDeprecationWarning by default, such that deprecation warnings in development\ntools that were themselves written in Python (e.g. linters, static analysers,\ntest runners, code generators), as well as any other applications that merely\nhappened to be written in Python, wouldn't be visible to their users unless\nthose users explicitly opted in to seeing them.\nHowever, this change has had the unfortunate side effect of making\nDeprecationWarning markedly less effective at its primary intended purpose:\nproviding advance notice of breaking changes in APIs (whether in CPython, the\nstandard library, or in third party libraries) to users of those APIs.\nTo improve this situation, this PEP proposes a single adjustment to the\ndefault warnings filter: displaying deprecation warnings attributed to the main\nmodule by default.\nThis change will mean that code entered at the interactive prompt and code in\nsingle file scripts will revert to reporting these warnings by default, while\nthey will continue to be silenced by default for packaged code distributed as\npart of an importable module.\nThe PEP also proposes a number of small adjustments to the reference\ninterpreter and standard library documentation to help make the warnings\nsubsystem more approachable for new Python developers.\nAs part of the documentation updates, it will be made clearer that the\nunittest test runner displays all warnings by default when executing\ntest cases, and that other test runners are advised to follow that example.\n"}, | |
| {"id": "566", "title": "Metadata for Python Software Packages 2.1", "authors": "Ingram", "discussions_to": "distutils-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "01-Dec-2017", "python_version": "3.x", "post_history": null, "resolution": "https://mail.python.org/pipermail/distutils-sig/2018-February/032014.html", "requires": null, "replaces": "345", "superseded_by": null, "url": "https://peps.python.org/pep-0566/", "abstract": "\nAbstract\nThis PEP describes the changes between versions 1.2 and 2.1 of the core\nmetadata specification for Python packages. Version 1.2 is specified in\nPEP 345.\nIt also changes to the canonical source for field specifications to the Core\nMetadata Specification reference document, which includes specifics of the\nfield names, and their semantics and usage.\n"}, | |
| {"id": "567", "title": "Context Variables", "authors": "Selivanov", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "12-Dec-2017", "python_version": "3.7", "post_history": "12-Dec-2017, 28-Dec-2017, 16-Jan-2018", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0567/", "abstract": "\nIntroduction\nThe PEP proposes a new mechanism for managing context variables.\nThe key classes involved in this mechanism are contextvars.Context\nand contextvars.ContextVar. The PEP also proposes some policies\nfor using the mechanism around asynchronous tasks.\nThe proposed mechanism for accessing context variables uses the\nContextVar class. A module (such as decimal) that wishes to\nuse the new mechanism should:\n\ndeclare a module-global variable holding a ContextVar to\nserve as a key;\naccess the current value via the get() method on the\nkey variable;\nmodify the current value via the set() method on the\nkey variable.\n\nThe notion of \"current value\" deserves special consideration:\ndifferent asynchronous tasks that exist and execute concurrently\nmay have different values for the same key. This idea is well known\nfrom thread-local storage but in this case the locality of the value is\nnot necessarily bound to a thread. Instead, there is the notion of the\n\"current Context\" which is stored in thread-local storage.\nManipulation of the current context is the responsibility of the\ntask framework, e.g. asyncio.\nA Context is a mapping of ContextVar objects to their values.\nThe Context itself exposes the abc.Mapping interface\n(not abc.MutableMapping!), so it cannot be modified directly.\nTo set a new value for a context variable in a Context object,\nthe user needs to:\n\nmake the Context object \"current\" using the Context.run()\nmethod;\nuse ContextVar.set() to set a new value for the context\nvariable.\n\nThe ContextVar.get() method looks for the variable in the current\nContext object using self as a key.\nIt is not possible to get a direct reference to the current Context\nobject, but it is possible to obtain a shallow copy of it using the\ncontextvars.copy_context() function. This ensures that the\ncaller of Context.run() is the sole owner of its Context\nobject.\n"}, | |
| {"id": "568", "title": "Generator-sensitivity for Context Variables", "authors": "Smith", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "04-Jan-2018", "python_version": "3.8", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0568/", "abstract": "\nAbstract\nContext variables provide a generic mechanism for tracking dynamic,\ncontext-local state, similar to thread-local storage but generalized\nto cope work with other kinds of thread-like contexts, such as asyncio\nTasks. PEP 550 proposed a mechanism for context-local state that was\nalso sensitive to generator context, but this was pretty complicated,\nso the BDFL requested it be simplified. The result was PEP 567, which\nis targeted for inclusion in 3.7. This PEP then extends PEP 567's\nmachinery to add generator context sensitivity.\nThis PEP is starting out in the \"deferred\" status, because there isn't\nenough time to give it proper consideration before the 3.7 feature\nfreeze. The only goal right now is to understand what would be\nrequired to add generator context sensitivity in 3.8, so that we can\navoid shipping something in 3.7 that would rule it out by accident.\n(Ruling it out on purpose can wait until 3.8 ;-).)\n"}, | |
| {"id": "569", "title": "Python 3.8 Release Schedule", "authors": "Langa", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "release", "created": "27-Jan-2018", "python_version": "3.8", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0569/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.8. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "570", "title": "Python Positional-Only Parameters", "authors": "Hastings, Galindo, Corchero, Vander Weele", "discussions_to": "https://discuss.python.org/t/pep-570-python-positional-only-parameters/1078", "status": "Final", "type": "Standards Track", "topic": "", "created": "20-Jan-2018", "python_version": "3.8", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0570/", "abstract": "\nAbstract\nThis PEP proposes to introduce a new syntax, /, for specifying\npositional-only parameters in Python function definitions.\nPositional-only parameters have no externally-usable name. When a function\naccepting positional-only parameters is called, positional arguments are mapped\nto these parameters based solely on their order.\nWhen designing APIs (application programming interfaces), library\nauthors try to ensure correct and intended usage of an API. Without the ability to\nspecify which parameters are positional-only, library authors must be careful\nwhen choosing appropriate parameter names. This care must be taken\neven for required parameters or when the parameters\nhave no external semantic meaning for callers of the API.\nIn this PEP, we discuss:\n\nPython's history and current semantics for positional-only parameters\nthe problems encountered by not having them\nhow these problems are handled without language-intrinsic support for\npositional-only parameters\nthe benefits of having positional-only parameters\n\nWithin context of the motivation, we then:\n\ndiscuss why positional-only parameters should be a feature intrinsic to the\nlanguage\npropose the syntax for marking positional-only parameters\npresent how to teach this new feature\nnote rejected ideas in further detail\n\n"}, | |
| {"id": "571", "title": "The manylinux2010 Platform Tag", "authors": "Williams, Thomas, Kluyver", "discussions_to": "distutils-sig@python.org", "status": "Superseded", "type": "Informational", "topic": "packaging", "created": "05-Feb-2018", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/pipermail/distutils-sig/2018-April/032156.html", "requires": null, "replaces": null, "superseded_by": "600", "url": "https://peps.python.org/pep-0571/", "abstract": "\nAbstract\nThis PEP proposes the creation of a manylinux2010 platform tag to\nsucceed the manylinux1 tag introduced by PEP 513. It also\nproposes that PyPI and pip both be updated to support uploading,\ndownloading, and installing manylinux2010 distributions on compatible\nplatforms.\n"}, | |
| {"id": "572", "title": "Assignment Expressions", "authors": "Angelico, Peters, GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Feb-2018", "python_version": "3.8", "post_history": "28-Feb-2018, 02-Mar-2018, 23-Mar-2018, 04-Apr-2018, 17-Apr-2018, 25-Apr-2018, 09-Jul-2018, 05-Aug-2019", "resolution": "https://mail.python.org/pipermail/python-dev/2018-July/154601.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0572/", "abstract": "\nAbstract\nThis is a proposal for creating a way to assign to variables within an\nexpression using the notation NAME := expr.\nAs part of this change, there is also an update to dictionary comprehension\nevaluation order to ensure key expressions are executed before value\nexpressions (allowing the key to be bound to a name and then re-used as part of\ncalculating the corresponding value).\nDuring discussion of this PEP, the operator became informally known as\n\"the walrus operator\". The construct's formal name is \"Assignment Expressions\"\n(as per the PEP title), but they may also be referred to as \"Named Expressions\"\n(e.g. the CPython reference implementation uses that name internally).\n"}, | |
| {"id": "573", "title": "Module State Access from C Extension Methods", "authors": "Viktorin, Coghlan, Snow, Plch", "discussions_to": "import-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "02-Jun-2016", "python_version": "3.9", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0573/", "abstract": "\nAbstract\nThis PEP proposes to add a way for CPython extension methods to access context,\nsuch as the state of the modules they are defined in.\nThis will allow extension methods to use direct pointer dereferences\nrather than PyState_FindModule for looking up module state, reducing or\neliminating the performance cost of using module-scoped state over process\nglobal state.\nThis fixes one of the remaining roadblocks for adoption of PEP 3121 (Extension\nmodule initialization and finalization) and PEP 489\n(Multi-phase extension module initialization).\nWhile this PEP takes an additional step towards fully solving the problems that\nPEP 3121 and PEP 489 started tackling, it does not attempt to resolve all\nremaining concerns. In particular, access to the module state\nfrom slot methods (nb_add, etc) is not solved.\n"}, | |
| {"id": "574", "title": "Pickle protocol 5 with out-of-band data", "authors": "Pitrou", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "23-Mar-2018", "python_version": "3.8", "post_history": "28-Mar-2018, 30-Apr-2019", "resolution": "https://mail.python.org/pipermail/python-dev/2019-May/157284.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0574/", "abstract": "\nAbstract\nThis PEP proposes to standardize a new pickle protocol version, and\naccompanying APIs to take full advantage of it:\n\nA new pickle protocol version (5) to cover the extra metadata needed\nfor out-of-band data buffers.\nA new PickleBuffer type for __reduce_ex__ implementations\nto return out-of-band data buffers.\nA new buffer_callback parameter when pickling, to handle out-of-band\ndata buffers.\nA new buffers parameter when unpickling to provide out-of-band data\nbuffers.\n\nThe PEP guarantees unchanged behaviour for anyone not using the new APIs.\n"}, | |
| {"id": "575", "title": "Unifying function/method classes", "authors": "Demeyer", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "27-Mar-2018", "python_version": "3.8", "post_history": "31-Mar-2018, 12-Apr-2018, 27-Apr-2018, 05-May-2018", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0575/", "abstract": "\nAbstract\nReorganize the class hierarchy for functions and methods\nwith the goal of reducing the difference between\nbuilt-in functions (implemented in C) and Python functions.\nMainly, make built-in functions behave more like Python functions\nwithout sacrificing performance.\nA new base class base_function is introduced and the various function\nclasses, as well as method (renamed to bound_method), inherit from it.\nWe also allow subclassing the Python function class.\n"}, | |
| {"id": "576", "title": "Rationalize Built-in function classes", "authors": "Shannon", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "10-May-2018", "python_version": "3.8", "post_history": "17-May-2018, 23-Jun-2018, 08-Jul-2018, 29-Mar-2019", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0576/", "abstract": "\nAbstract\nExpose the \"FastcallKeywords\" convention used internally by CPython to third-party code, and make the inspect module use duck-typing.\nIn combination this will allow third-party C extensions and tools like Cython to create objects that use the same calling conventions as built-in and Python functions, thus gaining performance parity with built-in functions like len or print.\nA small improvement in the performance of existing code is expected.\n"}, | |
| {"id": "577", "title": "Augmented Assignment Expressions", "authors": "Coghlan", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "14-May-2018", "python_version": "3.8", "post_history": "22-May-2018", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0577/", "abstract": "\nAbstract\nThis is a proposal to allow augmented assignments such as x += 1 to be\nused as expressions, not just statements.\nAs part of this, NAME := EXPR is proposed as an inline assignment expression\nthat uses the new augmented assignment scoping rules, rather than implicitly\ndefining a new local variable name the way that existing name binding\nstatements do. The question of allowing expression level local variable\ndeclarations at function scope is deliberately separated from the question of\nallowing expression level name bindings, and deferred to a later PEP.\nThis PEP is a direct competitor to PEP 572 (although it borrows heavily from that\nPEP's motivation, and even shares the proposed syntax for inline assignments).\nSee Relationship with PEP 572 for more details on the connections between\nthe two PEPs.\nTo improve the usability of the new expressions, a semantic split is proposed\nbetween the handling of augmented assignments in regular block scopes (modules,\nclasses, and functions), and the handling of augmented assignments in scoped\nexpressions (lambda expressions, generator expressions, and comprehensions),\nsuch that all inline assignments default to targeting the nearest containing\nblock scope.\nA new compile time TargetNameError is added as a subclass of SyntaxError\nto handle cases where it is deemed to be currently unclear which target is\nexpected to be rebound by an inline assignment, or else the target scope\nfor the inline assignment is considered invalid for another reason.\n"}, | |
| {"id": "578", "title": "Python Runtime Audit Hooks", "authors": "Dower", "discussions_to": null, "status": "Accepted", "type": "Standards Track", "topic": "", "created": "16-Jun-2018", "python_version": "3.8", "post_history": "28-Mar-2019, 07-May-2019", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0578/", "abstract": "\nAbstract\nThis PEP describes additions to the Python API and specific behaviors\nfor the CPython implementation that make actions taken by the Python\nruntime visible to auditing tools. Visibility into these actions\nprovides opportunities for test frameworks, logging frameworks, and\nsecurity tools to monitor and optionally limit actions taken by the\nruntime.\nThis PEP proposes adding two APIs to provide insights into a running\nPython application: one for arbitrary events, and another specific to\nthe module import system. The APIs are intended to be available in all\nPython implementations, though the specific messages and values used\nare unspecified here to allow implementations the freedom to determine\nhow best to provide information to their users. Some examples likely\nto be used in CPython are provided for explanatory purposes.\nSee PEP 551 for discussion and recommendations on enhancing the\nsecurity of a Python runtime making use of these auditing APIs.\n"}, | |
| {"id": "579", "title": "Refactoring C functions and methods", "authors": "Demeyer", "discussions_to": null, "status": "Final", "type": "Informational", "topic": "", "created": "04-Jun-2018", "python_version": null, "post_history": "20-Jun-2018", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0579/", "abstract": "\nAbstract\nThis meta-PEP collects various issues with CPython's existing implementation\nof built-in functions (functions implemented in C) and methods.\nFixing all these issues is too much for one PEP,\nso that will be delegated to other standards track PEPs.\nHowever, this PEP does give some brief ideas of possible fixes.\nThis is mainly meant to coordinate an overall strategy.\nFor example, a proposed solution may sound too complicated\nfor fixing any one single issue, but it may be the best overall\nsolution for multiple issues.\nThis PEP is purely informational:\nit does not imply that all issues will eventually\nbe fixed, nor that they will be fixed using the solution proposed here.\nIt also serves as a check-list of possible requested features\nto verify that a given fix does not make those\nother features harder to implement.\nThe major proposed change is replacing PyMethodDef\nby a new structure PyCCallDef\nwhich collects everything needed for calling the function/method.\nIn the PyTypeObject structure, a new field tp_ccalloffset\nis added giving an offset to a PyCCallDef * in the object structure.\nNOTE: This PEP deals only with CPython implementation details,\nit does not affect the Python language or standard library.\n"}, | |
| {"id": "580", "title": "The C call protocol", "authors": "Demeyer", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "14-Jun-2018", "python_version": "3.8", "post_history": "20-Jun-2018, 22-Jun-2018, 16-Jul-2018", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0580/", "abstract": "\nAbstract\nA new \"C call\" protocol is proposed.\nIt is meant for classes representing functions or methods\nwhich need to implement fast calling.\nThe goal is to generalize all existing optimizations for built-in functions\nto arbitrary extension types.\nIn the reference implementation,\nthis new protocol is used for the existing classes\nbuiltin_function_or_method and method_descriptor.\nHowever, in the future, more classes may implement it.\nNOTE: This PEP deals only with the Python/C API,\nit does not affect the Python language or standard library.\n"}, | |
| {"id": "581", "title": "Using GitHub Issues for CPython", "authors": "Mariatta", "discussions_to": "https://discuss.python.org/t/535", "status": "Accepted", "type": "Process", "topic": "", "created": "20-Jun-2018", "python_version": null, "post_history": "07-Mar-2019", "resolution": "https://mail.python.org/pipermail/python-dev/2019-May/157399.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0581/", "abstract": "\nAbstract\nThis PEP outlines the rationale for migration from Python's issue\ntracker on Roundup to GitHub issues. See PEP 588 for the detailed\nmigration plan.\n"}, | |
| {"id": "582", "title": "Python local packages directory", "authors": "Das, Dower, Stufft, Coghlan", "discussions_to": "https://discuss.python.org/t/pep-582-python-local-packages-directory/963/", "status": "Draft", "type": "Standards Track", "topic": "packaging", "created": "16-May-2018", "python_version": "3.12", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0582/", "abstract": "\nAbstract\nThis PEP proposes to add to Python a mechanism to automatically recognize a\n__pypackages__ directory and prefer importing packages installed in this\nlocation over user or global site-packages. This will avoid the steps to create,\nactivate or deactivate \"virtual environments\". Python will use the\n__pypackages__ from the base directory of the script when present.\n"}, | |
| {"id": "583", "title": "A Concurrency Memory Model for Python", "authors": "Yasskin", "discussions_to": null, "status": "Withdrawn", "type": "Informational", "topic": "", "created": "22-Mar-2008", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0583/", "abstract": "\nAbstract\nThis PEP describes how Python programs may behave in the presence of\nconcurrent reads and writes to shared variables from multiple threads.\nWe use a happens before relation to define when variable accesses\nare ordered or concurrent. Nearly all programs should simply use locks\nto guard their shared variables, and this PEP highlights some of the\nstrange things that can happen when they don't, but programmers often\nassume that it's ok to do \"simple\" things without locking, and it's\nsomewhat unpythonic to let the language surprise them. Unfortunately,\navoiding surprise often conflicts with making Python run quickly, so\nthis PEP tries to find a good tradeoff between the two.\n"}, | |
| {"id": "584", "title": "Add Union Operators To dict", "authors": "D'Aprano, Bucher", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-Mar-2019", "python_version": "3.9", "post_history": "01-Mar-2019, 16-Oct-2019, 02-Dec-2019, 04-Feb-2020, 17-Feb-2020", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/6KT2KIOTYXMDCD2CCAOLOI7LUGTN6MBS", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0584/", "abstract": "\nAbstract\nThis PEP proposes adding merge (|) and update (|=) operators\nto the built-in dict class.\n\nNote\nAfter this PEP was accepted, the decision was made to also\nimplement the new operators for several other standard library\nmappings.\n\n"}, | |
| {"id": "585", "title": "Type Hinting Generics In Standard Collections", "authors": "Langa", "discussions_to": "typing-sig@python.org", "status": "Final", "type": "Standards Track", "topic": "typing", "created": "03-Mar-2019", "python_version": "3.9", "post_history": null, "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/HW2NFOEMCVCTAFLBLC3V7MLM6ZNMKP42/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0585/", "abstract": "\nAbstract\nStatic typing as defined by PEPs 484, 526, 544, 560, and 563 was built\nincrementally on top of the existing Python runtime and constrained by\nexisting syntax and runtime behavior. This led to the existence of\na duplicated collection hierarchy in the typing module due to\ngenerics (for example typing.List and the built-in list).\nThis PEP proposes to enable support for the generics syntax in all\nstandard collections currently available in the typing module.\n"}, | |
| {"id": "586", "title": "Literal Types", "authors": "Lee, Levkivskyi, Lehtosalo", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "14-Mar-2019", "python_version": "3.8", "post_history": "14-Mar-2019", "resolution": "https://mail.python.org/archives/list/typing-sig@python.org/message/FDO4KFYWYQEP3U2HVVBEBR3SXPHQSHYR/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0586/", "abstract": "\nAbstract\nThis PEP proposes adding Literal types to the PEP 484 ecosystem.\nLiteral types indicate that some expression has literally a\nspecific value. For example, the following function will accept\nonly expressions that have literally the value \"4\":\nfrom typing import Literal\n\ndef accepts_only_four(x: Literal[4]) -> None:\n pass\n\naccepts_only_four(4) # OK\naccepts_only_four(19) # Rejected\n\n\n"}, | |
| {"id": "587", "title": "Python Initialization Configuration", "authors": "Stinner, Coghlan", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Mar-2019", "python_version": "3.8", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0587/", "abstract": "\nAbstract\nAdd a new C API to configure the Python Initialization providing finer\ncontrol on the whole configuration and better error reporting.\nIt becomes possible to read the configuration and then override some\ncomputed parameters before it is applied. It also becomes possible to\ncompletely override how Python computes the module search paths\n(sys.path).\nThe new Isolated Configuration provides sane default values to\nisolate Python from the system. For example, to embed Python into an\napplication. Using the environment are now opt-in options, rather than\nan opt-out options. For example, environment variables, command line\narguments and global configuration variables are ignored by default.\nBuilding a customized Python which behaves as the regular Python becomes\neasier using the new Py_RunMain() function. Moreover, using the\nPython Configuration, PyConfig.argv arguments are now parsed the\nsame way the regular Python parses command line arguments, and\nPyConfig.xoptions are handled as -X opt command line options.\nThis extracts a subset of the API design from the PEP 432 development\nand refactoring work that is now considered sufficiently stable to make\npublic (allowing 3rd party embedding applications access to the same\nconfiguration APIs that the native CPython CLI is now using).\n"}, | |
| {"id": "588", "title": "GitHub Issues Migration Plan", "authors": "Mariatta", "discussions_to": "https://discuss.python.org/t/13791", "status": "Draft", "type": "Informational", "topic": "", "created": "27-Mar-2019", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0588/", "abstract": "\nAbstract\nThis PEP describes the detailed plan for migrating from Python's issue\ntracker on Roundup to GitHub issues. See PEP 581 for rationale and\nbackground. PEP 588 also describes the detailed timeline for the\nmigration.\n"}, | |
| {"id": "589", "title": "TypedDict: Type Hints for Dictionaries with a Fixed Set of Keys", "authors": "Lehtosalo", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "20-Mar-2019", "python_version": "3.8", "post_history": null, "resolution": "https://mail.python.org/archives/list/typing-sig@python.org/message/FDO4KFYWYQEP3U2HVVBEBR3SXPHQSHYR/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0589/", "abstract": "\nAbstract\nPEP 484 defines the type Dict[K, V] for uniform\ndictionaries, where each value has the same type, and arbitrary key\nvalues are supported. It doesn't properly support the common pattern\nwhere the type of a dictionary value depends on the string value of\nthe key. This PEP proposes a type constructor typing.TypedDict to\nsupport the use case where a dictionary object has a specific set of\nstring keys, each with a value of a specific type.\nHere is an example where PEP 484 doesn't allow us to annotate\nsatisfactorily:\nmovie = {'name': 'Blade Runner',\n 'year': 1982}\n\n\nThis PEP proposes the addition of a new type constructor, called\nTypedDict, to allow the type of movie to be represented\nprecisely:\nfrom typing import TypedDict\n\nclass Movie(TypedDict):\n name: str\n year: int\n\n\nNow a type checker should accept this code:\nmovie: Movie = {'name': 'Blade Runner',\n 'year': 1982}\n\n\n"}, | |
| {"id": "590", "title": "Vectorcall: a fast calling protocol for CPython", "authors": "Shannon, Demeyer", "discussions_to": null, "status": "Accepted", "type": "Standards Track", "topic": "", "created": "29-Mar-2019", "python_version": "3.8", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0590/", "abstract": "\nAbstract\nThis PEP introduces a new C API to optimize calls of objects.\nIt introduces a new \"vectorcall\" protocol and calling convention.\nThis is based on the \"fastcall\" convention, which is already used internally by CPython.\nThe new features can be used by any user-defined extension class.\nMost of the new API is private in CPython 3.8.\nThe plan is to finalize semantics and make it public in Python 3.9.\nNOTE: This PEP deals only with the Python/C API,\nit does not affect the Python language or standard library.\n"}, | |
| {"id": "591", "title": "Adding a final qualifier to typing", "authors": "Sullivan, Levkivskyi", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "15-Mar-2019", "python_version": "3.8", "post_history": null, "resolution": "https://mail.python.org/archives/list/typing-sig@python.org/message/FDO4KFYWYQEP3U2HVVBEBR3SXPHQSHYR/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0591/", "abstract": "\nAbstract\nThis PEP proposes a \"final\" qualifier to be added to the typing\nmodule--in the form of a final decorator and a Final type\nannotation--to serve three related purposes:\n\nDeclaring that a method should not be overridden\nDeclaring that a class should not be subclassed\nDeclaring that a variable or attribute should not be reassigned\n\n"}, | |
| {"id": "592", "title": "Adding \"Yank\" Support to the Simple API", "authors": "Stufft", "discussions_to": "https://discuss.python.org/t/1629", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "07-May-2019", "python_version": null, "post_history": null, "resolution": "https://discuss.python.org/t/pep-592-support-for-yanked-files-in-the-simple-repository-api/1629/30", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0592/", "abstract": "\nAbstract\nThis PEP proposes adding the ability to mark a particular file download\non a simple repository as \"yanked\". Yanking a file allows authors to\neffectively delete a file, without breaking things for people who have\npinned to exactly a specific version.\nIt also changes to the canonical source for the simple repository API to\nthe Simple Repository API reference document.\n"}, | |
| {"id": "593", "title": "Flexible function and variable annotations", "authors": "Varoquaux, Kashin", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "26-Apr-2019", "python_version": "3.9", "post_history": "20-May-2019", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0593/", "abstract": "\nAbstract\nThis PEP introduces a mechanism to extend the type annotations from PEP\n484 with arbitrary metadata.\n"}, | |
| {"id": "594", "title": "Removing dead batteries from the standard library", "authors": "Heimes, Cannon", "discussions_to": "https://discuss.python.org/t/13508", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "20-May-2019", "python_version": "3.11", "post_history": "21-May-2019, 04-Feb-2022", "resolution": "https://discuss.python.org/t/13508/22", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0594/", "abstract": "\nAbstract\nThis PEP proposed a list of standard library modules to be removed from the\nstandard library. The modules are mostly historic data formats (e.g. Commodore\nand SUN file formats), APIs and operating systems that have been superseded a\nlong time ago (e.g. Mac OS 9), or modules that have security implications and\nbetter alternatives (e.g. password and login).\nThe PEP follows in the footsteps of other PEPS like PEP 3108. The\nStandard Library Reorganization proposal removed a bunch of modules from\nPython 3.0. In 2007, the PEP referred to maintenance burden as:\n\n\"Over the years, certain modules have become a heavy burden upon python-dev\nto maintain. In situations like this, it is better for the module to be\ngiven to the community to maintain to free python-dev to focus more on\nlanguage support and other modules in the standard library that do not take\nup an undue amount of time and effort.\"\nThe withdrawn PEP 206 from 2000 expresses issues with the Python standard\nlibrary in an unvarnished and forthright manner:\n\n\"[...] the standard library modules aren't always the best choices for a\njob. Some library modules were quick hacks (e.g. calendar,\ncommands), some were designed poorly and are now near-impossible to\nfix (cgi), and some have been rendered obsolete by other, more complete\nmodules [...].\"\n"}, | |
| {"id": "595", "title": "Improving bugs.python.org", "authors": "Melotti, Peksag", "discussions_to": null, "status": "Withdrawn", "type": "Informational", "topic": "", "created": "12-May-2019", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0595/", "abstract": "\nAbstract\nThis PEP proposes a list of improvements to make bugs.python.org\nmore usable for contributors and core developers. This PEP also\ndiscusses why remaining on Roundup should be preferred over\nswitching to GitHub Issues, as proposed by PEP 581.\n"}, | |
| {"id": "596", "title": "Python 3.9 Release Schedule", "authors": "Langa", "discussions_to": "https://discuss.python.org/t/pep-596-python-3-9-release-schedule-doubling-the-release-cadence/1828", "status": "Active", "type": "Informational", "topic": "release", "created": "04-Jun-2019", "python_version": "3.9", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0596/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.9. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "597", "title": "Add optional EncodingWarning", "authors": "Inada", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Jun-2019", "python_version": "3.10", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0597/", "abstract": "\nAbstract\nAdd a new warning category EncodingWarning. It is emitted when the\nencoding argument to open() is omitted and the default\nlocale-specific encoding is used.\nThe warning is disabled by default. A new -X warn_default_encoding\ncommand-line option and a new PYTHONWARNDEFAULTENCODING environment\nvariable can be used to enable it.\nA \"locale\" argument value for encoding is added too. It\nexplicitly specifies that the locale encoding should be used, silencing\nthe warning.\n"}, | |
| {"id": "598", "title": "Introducing incremental feature releases", "authors": "Coghlan", "discussions_to": "https://discuss.python.org/t/pep-596-python-3-9-release-schedule-doubling-the-release-cadence/1828", "status": "Withdrawn", "type": "Informational", "topic": "", "created": "15-Jun-2019", "python_version": "3.9", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0598/", "abstract": "\nAbstract\nPEP 602 proposes reducing the feature delivery latency for the Python\nstandard library and CPython reference interpreter by increasing the frequency\nof CPython feature releases from every 18-24 months to instead occur every 9-12\nmonths.\nThis PEP proposes to instead reduce the frequency of new baseline feature\nreleases (with the associated filesystem layout changes, bytecode format\nchanges, and C ABI compatibility breaks) to occur only every other year (2020,\n2022, 2024, etc), but to combine that change with a new policy and approach that\nallows the introduction of backwards compatible features in the initial set of\npoint releases within a given release series.\n"}, | |
| {"id": "599", "title": "The manylinux2014 Platform Tag", "authors": "Ingram", "discussions_to": "https://discuss.python.org/t/the-next-manylinux-specification/1043", "status": "Superseded", "type": "Informational", "topic": "packaging", "created": "29-Apr-2019", "python_version": null, "post_history": "29-Apr-2019", "resolution": "https://discuss.python.org/t/the-next-manylinux-specification/1043/199", "requires": null, "replaces": null, "superseded_by": "600", "url": "https://peps.python.org/pep-0599/", "abstract": "\nAbstract\nThis PEP proposes the creation of a manylinux2014 platform tag to\nsucceed the manylinux2010 tag introduced by PEP 513. It also\nproposes that PyPI and pip both be updated to support uploading,\ndownloading, and installing manylinux2014 distributions on\ncompatible platforms.\n"}, | |
| {"id": "600", "title": "Future 'manylinux' Platform Tags for Portable Linux Built Distributions", "authors": "Smith, Kluyver", "discussions_to": "https://discuss.python.org/t/the-next-manylinux-specification/1043", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "03-May-2019", "python_version": null, "post_history": "03-May-2019", "resolution": "https://discuss.python.org/t/pep-600-future-manylinux-platform-tags-for-portable-linux-built-distributions/2414/27", "requires": null, "replaces": "513, 571, 599", "superseded_by": null, "url": "https://peps.python.org/pep-0600/", "abstract": "\nAbstract\nThis PEP proposes a scheme for new 'manylinux' wheel tags to be\ndefined without requiring a PEP for every specific tag, similar to how\nWindows and macOS tags already work. This will allow package\nmaintainers to take advantage of new tags more quickly, while making\nbetter use of limited volunteer time.\nNon-goals include: handling non-glibc-based platforms; integrating\nwith external package managers or handling external dependencies such\nas CUDA; making manylinux tags more sophisticated than their\nWindows/macOS equivalents; doing anything besides taking our existing\ntried-and-tested approach and streamlining it. These are important\nissues and other PEPs may address them in the future, but for this PEP\nthey're out of scope.\n"}, | |
| {"id": "601", "title": "Forbid return/break/continue breaking out of finally", "authors": "George, Taskaya", "discussions_to": "https://discuss.python.org/t/pep-601-forbid-return-break-continue-breaking-out-of-finally/2239", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "26-Aug-2019", "python_version": "3.8", "post_history": "26-Aug-2019, 23-Sep-2019", "resolution": "https://discuss.python.org/t/pep-601-forbid-return-break-continue-breaking-out-of-finally/2239/32", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0601/", "abstract": "\nAbstract\nThis PEP proposes to forbid return, break and continue statements within\na finally suite where they would break out of the finally. Their use in\nsuch a location silently cancels any active exception being raised through\nthe finally, leading to unclear code and possible bugs.\ncontinue is currently not supported in a finally in Python 3.7 (due to\nimplementation issues) and the proposal is to not add support for it in\nPython 3.8. For return and break the proposal is to deprecate their use\nin Python 3.9, emit a compilation warning in Python 3.10 and then forbid\ntheir use after that.\n"}, | |
| {"id": "602", "title": "Annual Release Cycle for Python", "authors": "Langa", "discussions_to": "https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/", "status": "Accepted", "type": "Informational", "topic": "", "created": "04-Jun-2019", "python_version": "3.9", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0602/", "abstract": "\nAbstract\nThis document describes a change in the release calendar for Python\nstarting with Python 3.9. This change accelerates the release cadence\nsuch that major versions are released predictably every twelve months,\nin October every year.\n"}, | |
| {"id": "603", "title": "Adding a frozenmap type to collections", "authors": "Selivanov", "discussions_to": "https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318/", "status": "Draft", "type": "Standards Track", "topic": "", "created": "12-Sep-2019", "python_version": null, "post_history": "12-Sep-2019", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0603/", "abstract": "\nAbstract\nA persistent data structure is defined as a data structure that\npreserves the previous version of the data when the data is modified.\nSuch data structures are effectively immutable, as operations on\nthem do not update the structure in-place, but instead always yield\na new updated structure (see [0] for more details.)\nThis PEP proposes to add a new fully persistent and immutable mapping\ntype called frozenmap to the collections module.\nThe bulk of frozenmap's reference implementation is already\nused in CPython to implement the contextvars module.\n"}, | |
| {"id": "604", "title": "Allow writing union types as ``X | Y``", "authors": "PRADOS, Moss", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "28-Aug-2019", "python_version": "3.10", "post_history": "28-Aug-2019, 05-Aug-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0604/", "abstract": "\nAbstract\nThis PEP proposes overloading the | operator on types to allow\nwriting Union[X, Y] as X | Y, and allows it to appear in\nisinstance and issubclass calls.\n"}, | |
| {"id": "605", "title": "A rolling feature release stream for CPython", "authors": "Dower, Coghlan", "discussions_to": "https://discuss.python.org/t/pep-605-a-rolling-feature-release-stream-for-cpython/2418", "status": "Rejected", "type": "Informational", "topic": "", "created": "20-Sep-2019", "python_version": "3.9", "post_history": "01-Oct-2019, 06-Oct-2019, 20-Oct-2019", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0605/", "abstract": "\nAbstract\nFor a long time, CPython's nominal feature release cadence has been \"every 18-24\nmonths\", and in recent years, has been pretty consistently on the \"18 month\"\nend of that window. PEP 607 provides some common background on the problems\nthat arise due to that choice of cadence, as well as some of the risks that\nneed to be accounted for when proposing to change it.\nThe proposal in this PEP aims to allow CPython's user base to self-select into\ntwo distinct but overlapping groups:\n\nusers of stable feature releases (and their associated maintenance release\nstreams) that are published every 24 months; and\nearly adopters of a new rolling release stream that takes the place of the\nprevious CPython pre-release process\n\nAs part of this proposal, the usage guidance given for beta releases would\nbecome \"suitable for production use only in environments with sufficiently\nrobust compatibility testing and operational monitoring capabilities\", rather\nthan the currently unqualified \"not for production use\".\nSimilarly, the guidance given for alpha releases would be amended to state\n\"intended for library compatibility testing and the creation of ABI compatible\nbinary artifacts\", rather than simply saying \"not for production use\".\nThe PEP authors believe these outcomes can be achieved by amending CPython's\npre-release management process as described in the Proposal section below.\nThis PEP also proposes that the frequency of X.Y.0 releases be adjusted to\nbegin each new release series in August every two years (starting in 2021,\naround two years after the release of Python 3.8.0).\n"}, | |
| {"id": "606", "title": "Python Compatibility Version", "authors": "Stinner", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "18-Oct-2019", "python_version": "3.9", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0606/", "abstract": "\nAbstract\nAdd sys.set_python_compat_version(version) to enable partial\ncompatibility with requested Python version. Add\nsys.get_python_compat_version().\nModify a few functions in the standard library to implement partial\ncompatibility with Python 3.8.\nAdd sys.set_python_min_compat_version(version) to deny backward\ncompatibility with Python versions older than version.\nAdd -X compat_version=VERSION and -X min_compat_version=VERSION\ncommand line options. Add PYTHONCOMPATVERSION and\nPYTHONCOMPATMINVERSION environment variables.\n"}, | |
| {"id": "607", "title": "Reducing CPython's Feature Delivery Latency", "authors": "Langa, Dower, Coghlan", "discussions_to": "https://discuss.python.org/t/pep-607-shared-background-for-the-release-cadence-peps/2528", "status": "Final", "type": "Informational", "topic": "", "created": "11-Oct-2019", "python_version": "3.9", "post_history": "20-Oct-2019", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0607/", "abstract": "\nAbstract\nPEP 602 and PEP 605 describe two alternative approaches to delivering smaller\ncollections of features to Python's users more frequently (as compared to the\ncurrent approach of offering new feature releases every 18-24 months, with\nthe first binary alpha release taking place 6-8 months before the final release).\nBoth PEPs also propose moving to a release cadence that results in full releases\noccurring at a consistent time of year (every year for PEP 602, every other\nyear for PEP 605).\nThis PEP (from the authors of both competing proposals) provides common\nbackground on why a change in the release cadence is considered desirable,\nas well as the perceived risks that both PEPs attempt to mitigate.\n"}, | |
| {"id": "608", "title": "Coordinated Python release", "authors": "Hron\u010dok, Stinner", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "25-Oct-2019", "python_version": "3.9", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0608/", "abstract": "\nAbstract\nBlock a Python release until a compatible version of selected projects\nis available.\nThe Python release manager can decide to release Python even if a\nproject is not compatible, if they decide that the project is going to\nbe fixed soon enough, or if the issue severity is low enough.\n"}, | |
| {"id": "609", "title": "Python Packaging Authority (PyPA) Governance", "authors": "Ingram, Gedam, Harihareswara", "discussions_to": "https://discuss.python.org/t/pep-609-pypa-governance/2619", "status": "Active", "type": "Process", "topic": "packaging", "created": "05-Nov-2019", "python_version": null, "post_history": "05-Nov-2019", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0609/", "abstract": "\nAbstract\nThis document describes a governance model for the Python Packaging\nAuthority (PyPA). The model is closely based on existing informal\npractices, with the intent of providing clarity into the functioning\nof the PyPA and formalizing transparent processes for the PyPA.\n"}, | |
| {"id": "610", "title": "Recording the Direct URL Origin of installed distributions", "authors": "Bidoul, Jerdonek", "discussions_to": "https://discuss.python.org/t/recording-the-source-url-of-an-installed-distribution/1535", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "21-Apr-2019", "python_version": null, "post_history": null, "resolution": "https://discuss.python.org/t/1535/56", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0610/", "abstract": "\nAbstract\nFollowing PEP 440, a distribution can be identified by a name and either a\nversion, or a direct URL reference (see PEP440 Direct References).\nAfter installation, the name and version are captured in the project metadata,\nbut currently there is no way to obtain details of the URL used when the\ndistribution was identified by a direct URL reference.\nThis proposal defines\nadditional metadata, to be added to the installed distribution by the\ninstallation front end, which records the Direct URL Origin for use by\nconsumers which introspect the database of installed packages (see PEP 376).\n"}, | |
| {"id": "611", "title": "The one million limit", "authors": "Shannon", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "05-Dec-2019", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0611/", "abstract": "\nAbstract\nThis PR proposes a soft limit of one million (1 000 000), and a larger hard limit\nfor various aspects of Python code and its implementation.\nThe Python language does not specify limits for many of its features.\nNot having any limit to these values seems to enhance programmer freedom,\nat least superficially, but in practice the CPython VM and other Python virtual\nmachines have implicit limits or are forced to assume that the limits are\nastronomical, which is expensive.\nThis PR lists a number of features which are to have a limit of one million.\nFor CPython the hard limit will be eight million (8 000 000).\n"}, | |
| {"id": "612", "title": "Parameter Specification Variables", "authors": "Mendoza", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "18-Dec-2019", "python_version": "3.10", "post_history": "18-Dec-2019, 13-Jul-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0612/", "abstract": "\nAbstract\nThere currently are two ways to specify the type of a callable, the\nCallable[[int, str], bool] syntax defined in PEP 484,\nand callback protocols from PEP\n544. Neither of\nthese support forwarding the parameter types of one callable over to another\ncallable, making it difficult to annotate function decorators. This PEP proposes\ntyping.ParamSpec and typing.Concatenate to\nsupport expressing these kinds of relationships.\n"}, | |
| {"id": "613", "title": "Explicit Type Aliases", "authors": "Zhu", "discussions_to": "https://mail.python.org/archives/list/typing-sig@python.org/thread/MWRJOBEEEMFVXE7CAKO7B4P46IPM4AN3/", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "21-Jan-2020", "python_version": "3.10", "post_history": "21-Jan-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0613/", "abstract": "\nAbstract\nType aliases are user-specified types which may be as complex as any type hint,\nand are specified with a simple variable assignment on a module top level.\nThis PEP formalizes a way to explicitly declare an assignment as a type alias.\n"}, | |
| {"id": "614", "title": "Relaxing Grammar Restrictions On Decorators", "authors": "Bucher", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "10-Feb-2020", "python_version": "3.9", "post_history": "11-Feb-2020, 18-Feb-2020, 03-Mar-2020", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/VSR66MOTCDCY7ZFH4IG7QVFI2JXQQZQ5", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0614/", "abstract": "\nAbstract\nPython currently requires that all decorators consist of a dotted\nname, optionally followed by a single call. This PEP proposes removing\nthese limitations and allowing decorators to be any valid expression.\n"}, | |
| {"id": "615", "title": "Support for the IANA Time Zone Database in the Standard Library", "authors": "Ganssle", "discussions_to": "https://discuss.python.org/t/3468", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "22-Feb-2020", "python_version": "3.9", "post_history": "25-Feb-2020, 29-Mar-2020", "resolution": null, "requires": null, "replaces": "431", "superseded_by": null, "url": "https://peps.python.org/pep-0615/", "abstract": "\nAbstract\nThis proposes adding a module, zoneinfo, to provide a concrete time zone\nimplementation supporting the IANA time zone database. By default,\nzoneinfo will use the system's time zone data if available; if no system\ntime zone data is available, the library will fall back to using the\nfirst-party package tzdata, deployed on PyPI. [d]\n"}, | |
| {"id": "616", "title": "String methods to remove prefixes and suffixes", "authors": "Sweeney", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Mar-2020", "python_version": "3.9", "post_history": "20-Mar-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0616/", "abstract": "\nAbstract\nThis is a proposal to add two new methods, removeprefix() and\nremovesuffix(), to the APIs of Python's various string objects. These\nmethods would remove a prefix or suffix (respectively) from a string,\nif present, and would be added to Unicode str objects, binary\nbytes and bytearray objects, and collections.UserString.\n"}, | |
| {"id": "617", "title": "New PEG parser for CPython", "authors": "GvR, Galindo, Nikolaou", "discussions_to": "python-dev@python.org", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "24-Mar-2020", "python_version": "3.9", "post_history": "02-Apr-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0617/", "abstract": ""}, | |
| {"id": "618", "title": "Add Optional Length-Checking To zip", "authors": "Bucher", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-May-2020", "python_version": "3.10", "post_history": "01-May-2020, 10-May-2020, 16-Jun-2020", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/NLWB7FVJGMBBMCF4P3ZKUIE53JPDOWJ3", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0618/", "abstract": "\nAbstract\nThis PEP proposes adding an optional strict boolean keyword\nparameter to the built-in zip. When enabled, a ValueError is\nraised if one of the arguments is exhausted before the others.\n"}, | |
| {"id": "619", "title": "Python 3.10 Release Schedule", "authors": "Salgado", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "release", "created": "25-May-2020", "python_version": "3.10", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0619/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.10. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "620", "title": "Hide implementation details from the C API", "authors": "Stinner", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "", "created": "19-Jun-2020", "python_version": "3.12", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0620/", "abstract": "\nAbstract\nIntroduce C API incompatible changes to hide implementation details.\nOnce most implementation details will be hidden, evolution of CPython\ninternals would be less limited by C API backward compatibility issues.\nIt will be way easier to add new features.\nIt becomes possible to experiment with more advanced optimizations in\nCPython than just micro-optimizations, like tagged pointers.\nDefine a process to reduce the number of broken C extensions.\nThe implementation of this PEP is expected to be done carefully over\nmultiple Python versions. It already started in Python 3.7 and most\nchanges are already completed. The Process to reduce the number of\nbroken C extensions dictates the rhythm.\n"}, | |
| {"id": "621", "title": "Storing project metadata in pyproject.toml", "authors": "Cannon, Ingram, Ganssle, Gedam, Eustace, Kluyver, Chung", "discussions_to": "https://discuss.python.org/t/pep-621-round-3/5472", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "22-Jun-2020", "python_version": null, "post_history": "22-Jun-2020, 18-Oct-2020, 24-Oct-2020, 31-Oct-2020", "resolution": "https://discuss.python.org/t/pep-621-round-3/5472/109", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0621/", "abstract": "\nAbstract\nThis PEP specifies how to write a project's core metadata in a\npyproject.toml file for packaging-related tools to consume.\n"}, | |
| {"id": "622", "title": "Structural Pattern Matching", "authors": "Bucher, Moisset, Kohn, Levkivskyi, GvR, Talin", "discussions_to": "python-dev@python.org", "status": "Superseded", "type": "Standards Track", "topic": "", "created": "23-Jun-2020", "python_version": "3.10", "post_history": "23-Jun-2020, 08-Jul-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": "634", "url": "https://peps.python.org/pep-0622/", "abstract": "\nAbstract\nThis PEP proposes to add a pattern matching statement to Python,\ninspired by similar syntax found in Scala, Erlang, and other languages.\n\nPatterns and shapes\nThe pattern syntax builds on Python's existing syntax for sequence\nunpacking (e.g., a, b = value).\nA match statement compares a value (the subject)\nto several different shapes (the patterns) until a shape fits.\nEach pattern describes the type and structure of the accepted values\nas well as the variables where to capture its contents.\nPatterns can specify the shape to be:\n\na sequence to be unpacked, as already mentioned\na mapping with specific keys\nan instance of a given class with (optionally) specific attributes\na specific value\na wildcard\n\nPatterns can be composed in several ways.\n\n\nSyntax\nSyntactically, a match statement contains:\n\na subject expression\none or more case clauses\n\nEach case clause specifies:\n\na pattern (the overall shape to be matched)\nan optional \"guard\" (a condition to be checked if the pattern matches)\na code block to be executed if the case clause is selected\n\n\n\nMotivation\nThe rest of the PEP:\n\nmotivates why we believe pattern matching makes a good addition to Python\nexplains our design choices\ncontains a precise syntactic and runtime specification\ngives guidance for static type checkers (and one small addition to the typing module)\ndiscusses the main objections and alternatives that have been\nbrought up during extensive discussion of the proposal, both within\nthe group of authors and in the python-dev community\n\nFinally, we discuss some possible extensions that might be considered\nin the future, once the community has ample experience with the\ncurrently proposed syntax and semantics.\n\n"}, | |
| {"id": "623", "title": "Remove wstr from Unicode", "authors": "Inada", "discussions_to": "https://mail.python.org/archives/list/python-dev@python.org/thread/BO2TQHSXWL2RJMINWQQRBF5LANDDJNHH/", "status": "Final", "type": "Standards Track", "topic": "", "created": "25-Jun-2020", "python_version": "3.10", "post_history": null, "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/VQKDIZLZ6HF2MLTNCUFURK2IFTXVQEYA/#VQKDIZLZ6HF2MLTNCUFURK2IFTXVQEYA", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0623/", "abstract": "\nAbstract\nPEP 393 deprecated some unicode APIs, and introduced wchar_t *wstr,\nand Py_ssize_t wstr_length in the Unicode structure to support\nthese deprecated APIs.\nThis PEP is planning removal of wstr, and wstr_length with\ndeprecated APIs using these members by Python 3.12.\nDeprecated APIs which doesn't use the members are out of scope because\nthey can be removed independently.\n"}, | |
| {"id": "624", "title": "Remove Py_UNICODE encoder APIs", "authors": "Inada", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "06-Jul-2020", "python_version": "3.11", "post_history": "08-Jul-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0624/", "abstract": "\nAbstract\nThis PEP proposes to remove deprecated Py_UNICODE encoder APIs in Python 3.11:\n\nPyUnicode_Encode()\nPyUnicode_EncodeASCII()\nPyUnicode_EncodeLatin1()\nPyUnicode_EncodeUTF7()\nPyUnicode_EncodeUTF8()\nPyUnicode_EncodeUTF16()\nPyUnicode_EncodeUTF32()\nPyUnicode_EncodeUnicodeEscape()\nPyUnicode_EncodeRawUnicodeEscape()\nPyUnicode_EncodeCharmap()\nPyUnicode_TranslateCharmap()\nPyUnicode_EncodeDecimal()\nPyUnicode_TransformDecimalToASCII()\n\n\nNote\nPEP 623 propose to remove\nUnicode object APIs relating to Py_UNICODE. On the other hand, this PEP\nis not relating to Unicode object. These PEPs are split because they have\ndifferent motivations and need different discussions.\n\n"}, | |
| {"id": "625", "title": "Filename of a Source Distribution", "authors": "Chung, Moore", "discussions_to": "https://discuss.python.org/t/draft-pep-file-name-of-a-source-distribution/4686", "status": "Accepted", "type": "Standards Track", "topic": "packaging", "created": "08-Jul-2020", "python_version": null, "post_history": "08-Jul-2020", "resolution": "https://discuss.python.org/t/pep-625-file-name-of-a-source-distribution/4686/159", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0625/", "abstract": "\nAbstract\nThis PEP describes a standard naming scheme for a Source Distribution, also\nknown as an sdist. An sdist is distinct from an arbitrary archive file\ncontaining source code of Python packages, and can be used to communicate\ninformation about the distribution to packaging tools.\nA standard sdist specified here is a gzipped tar file with a specially\nformatted filename and the usual .tar.gz suffix. This PEP does not specify\nthe contents of the tarball, as that is covered in other specifications.\n"}, | |
| {"id": "626", "title": "Precise line numbers for debugging and other tools.", "authors": "Shannon", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Jul-2020", "python_version": "3.10", "post_history": "17-Jul-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0626/", "abstract": "\nAbstract\nPython should guarantee that when tracing is turned on, \"line\" tracing events are generated for all lines of code executed and only for lines of\ncode that are executed.\nThe f_lineno attribute of frame objects should always contain the expected line number.\nDuring frame execution, the expected line number is the line number of source code currently being executed.\nAfter a frame has completed, either by returning or by raising an exception,\nthe expected line number is the line number of the last line of source that was executed.\nA side effect of ensuring correct line numbers, is that some bytecodes will need to be marked as artificial, and not have a meaningful line number.\nTo assist tools, a new co_lines attribute will be added that describes the mapping from bytecode to source.\n"}, | |
| {"id": "627", "title": "Recording installed projects", "authors": "Viktorin", "discussions_to": "https://discuss.python.org/t/pep-627/4126", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "15-Jul-2020", "python_version": null, "post_history": null, "resolution": "https://discuss.python.org/t/pep-627/4126/42", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0627/", "abstract": "\nAbstract\nThis PEP clarifies and updates PEP 376 (Database of Installed Python\nDistributions), rewriting it as an interoperability standard.\nIt moves the canonical location of the standard to the Python\nPackaging Authority (PyPA) standards repository, and sets up guidelines\nfor changing it.\nTwo files in installed .dist-info directories are made optional:\nRECORD (which PEP 376 lists as mandatory, but suggests it can be left out\nfor \"system packages\"), and INSTALLER.\n"}, | |
| {"id": "628", "title": "Add ``math.tau``", "authors": "Coghlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Jun-2011", "python_version": "3.6", "post_history": "28-Jun-2011", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0628/", "abstract": "\nAbstract\nIn honour of Tau Day 2011, this PEP proposes the addition of the circle\nconstant math.tau to the Python standard library.\nThe concept of tau (\u03c4) is based on the observation that the ratio of a\ncircle's circumference to its radius is far more fundamental and interesting\nthan the ratio between its circumference and diameter. It is simply a matter\nof assigning a name to the value 2 * pi (2\u03c0).\n"}, | |
| {"id": "629", "title": "Versioning PyPI's Simple API", "authors": "Stufft", "discussions_to": "https://discuss.python.org/t/pep-629-versioning-pypis-simple-api/4720", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "16-Jul-2020", "python_version": null, "post_history": "16-Jul-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0629/", "abstract": "\nAbstract\nThis PEP proposes adding a method for versioning the simple API so\nthat clients can determine which features of the simple API that a\nspecific repository supports.\n"}, | |
| {"id": "630", "title": "Isolating Extension Modules", "authors": "Viktorin", "discussions_to": "capi-sig@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "25-Aug-2020", "python_version": null, "post_history": "16-Jul-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0630/", "abstract": "\nAbstract\nTraditionally, state belonging to Python extension modules was kept in C\nstatic variables, which have process-wide scope. This document\ndescribes problems of such per-process state and efforts to make\nper-module state--a better default--possible and easy to use.\nThe document also describes how to switch to per-module state where\npossible. This transition involves allocating space for that state, potentially\nswitching from static types to heap types, and--perhaps most\nimportantly--accessing per-module state from code.\n"}, | |
| {"id": "631", "title": "Dependency specification in pyproject.toml based on PEP 508", "authors": "Lev", "discussions_to": "https://discuss.python.org/t/5018", "status": "Superseded", "type": "Standards Track", "topic": "packaging", "created": "20-Aug-2020", "python_version": null, "post_history": "20-Aug-2020", "resolution": "https://discuss.python.org/t/how-to-specify-dependencies-pep-508-strings-or-a-table-in-toml/5243/38", "requires": null, "replaces": null, "superseded_by": "621", "url": "https://peps.python.org/pep-0631/", "abstract": "\nAbstract\nThis PEP specifies how to write a project's dependencies in a\npyproject.toml file for packaging-related tools to consume\nusing the fields defined in PEP 621.\n\nNote\nThis PEP has been accepted and was merged into PEP 621.\n\n"}, | |
| {"id": "632", "title": "Deprecate distutils module", "authors": "Dower", "discussions_to": "https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "03-Sep-2020", "python_version": "3.10", "post_history": "03-Sep-2020, 22-Jan-2021", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/TXU6TVOMBLQU3SV57DMMOA5Y2E67AW7P/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0632/", "abstract": "\nAbstract\nThe distutils module [1] has for a long time recommended using the\nsetuptools package [2] instead. Setuptools has recently integrated a\ncomplete copy of distutils and is no longer dependent on the standard\nlibrary [3]. Pip has been silently replacing distutils with\nsetuptools when installing packages for a long time already, and the\ndistutils documentation has stated that it is being phased out since\n2014 (or earlier). It is time to remove it from the standard library.\n"}, | |
| {"id": "633", "title": "Dependency specification in pyproject.toml using an exploded TOML table", "authors": "Opperman, Neelicattu", "discussions_to": "https://discuss.python.org/t/dependency-specification-in-pyproject-toml-using-an-exploded-toml-table/5123/", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "02-Sep-2020", "python_version": null, "post_history": "02-Sep-2020", "resolution": "https://discuss.python.org/t/how-to-specify-dependencies-pep-508-strings-or-a-table-in-toml/5243/38", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0633/", "abstract": "\nAbstract\nThis PEP specifies how to write a project's dependencies in a\npyproject.toml file for packaging-related tools to consume using the fields\ndefined in PEP 621, as an alternative to the PEP 508-based approach\ndefined in PEP 631.\n"}, | |
| {"id": "634", "title": "Structural Pattern Matching: Specification", "authors": "Bucher, GvR", "discussions_to": "python-dev@python.org", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "12-Sep-2020", "python_version": "3.10", "post_history": "22-Oct-2020, 08-Feb-2021", "resolution": "https://mail.python.org/archives/list/python-committers@python.org/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3", "requires": null, "replaces": "622", "superseded_by": null, "url": "https://peps.python.org/pep-0634/", "abstract": "\nAbstract\nThis PEP provides the technical specification for the match\nstatement. It replaces PEP 622, which is hereby split in three parts:\n\nPEP 634: Specification\nPEP 635: Motivation and Rationale\nPEP 636: Tutorial\n\nThis PEP is intentionally devoid of commentary; the motivation and all\nexplanations of our design choices are in PEP 635. First-time readers\nare encouraged to start with PEP 636, which provides a gentler\nintroduction to the concepts, syntax and semantics of patterns.\n"}, | |
| {"id": "635", "title": "Structural Pattern Matching: Motivation and Rationale", "authors": "Kohn, GvR", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "12-Sep-2020", "python_version": "3.10", "post_history": "22-Oct-2020, 08-Feb-2021", "resolution": "https://mail.python.org/archives/list/python-committers@python.org/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0635/", "abstract": "\nAbstract\nThis PEP provides the motivation and rationale for PEP 634\n(\"Structural Pattern Matching: Specification\"). First-time readers\nare encouraged to start with PEP 636, which provides a gentler\nintroduction to the concepts, syntax and semantics of patterns.\n"}, | |
| {"id": "636", "title": "Structural Pattern Matching: Tutorial", "authors": "Moisset", "discussions_to": "python-dev@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "12-Sep-2020", "python_version": "3.10", "post_history": "22-Oct-2020, 08-Feb-2021", "resolution": "https://mail.python.org/archives/list/python-committers@python.org/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0636/", "abstract": "\nAbstract\nThis PEP is a tutorial for the pattern matching introduced by PEP 634.\nPEP 622 proposed syntax for pattern matching, which received detailed discussion\nboth from the community and the Steering Council. A frequent concern was\nabout how easy it would be to explain (and learn) this feature. This PEP\naddresses that concern providing the kind of document which developers could use\nto learn about pattern matching in Python.\nThis is considered supporting material for PEP 634 (the technical specification\nfor pattern matching) and PEP 635 (the motivation and rationale for having pattern\nmatching and design considerations).\nFor readers who are looking more for a quick review than for a tutorial,\nsee Appendix A.\n"}, | |
| {"id": "637", "title": "Support for indexing with keyword arguments", "authors": "Borini", "discussions_to": "python-ideas@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "24-Aug-2020", "python_version": "3.10", "post_history": "23-Sep-2020", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/6TAQ2BEVSJNV4JM2RJYSSYFJUT3INGZD/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0637/", "abstract": "\nAbstract\nAt present keyword arguments are allowed in function calls, but not in\nitem access. This PEP proposes that Python be extended to allow keyword\narguments in item access.\nThe following example shows keyword arguments for ordinary function calls:\n>>> val = f(1, 2, a=3, b=4)\n\n\nThe proposal would extend the syntax to allow a similar construct\nto indexing operations:\n>>> val = x[1, 2, a=3, b=4] # getitem\n>>> x[1, 2, a=3, b=4] = val # setitem\n>>> del x[1, 2, a=3, b=4] # delitem\n\n\nand would also provide appropriate semantics. Single- and double-star unpacking of\narguments is also provided:\n>>> val = x[*(1, 2), **{a=3, b=4}] # Equivalent to above.\n\n\nThis PEP is a successor to PEP 472, which was rejected due to lack of\ninterest in 2019. Since then there's been renewed interest in the feature.\n"}, | |
| {"id": "638", "title": "Syntactic Macros", "authors": "Shannon", "discussions_to": "https://mail.python.org/archives/list/python-dev@python.org/thread/U4C4XHNRC4SHS3TPZWCTY4SN4QU3TT6V/", "status": "Draft", "type": "Standards Track", "topic": "", "created": "24-Sep-2020", "python_version": null, "post_history": "26-Sep-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0638/", "abstract": "\nAbstract\nThis PEP adds support for syntactic macros to Python.\nA macro is a compile-time function that transforms\na part of the program to allow functionality that cannot be\nexpressed cleanly in normal library code.\nThe term \"syntactic\" means that this sort of macro operates on the program's\nsyntax tree. This reduces the chance of mistranslation that can happen\nwith text-based substitution macros, and allows the implementation\nof hygienic macros.\nSyntactic macros allow libraries to modify the abstract syntax tree during compilation,\nproviding the ability to extend the language for specific domains without\nadding to complexity to the language as a whole.\n"}, | |
| {"id": "639", "title": "Improving License Clarity with Better Package Metadata", "authors": "Ombredanne, Gerlach", "discussions_to": "https://discuss.python.org/t/12622", "status": "Draft", "type": "Standards Track", "topic": "packaging", "created": "15-Aug-2019", "python_version": null, "post_history": "`15-Aug-2019 <https://discuss.python.org/t/2154>`__, `17-Dec-2021 <https://discuss.python.org/t/12622>`__,", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0639/", "abstract": "\nAbstract\nThis PEP defines a specification for how licenses are documented in the\ncore metadata, with\nlicense expression strings using\nSPDX identifiers in a new License-Expression field.\nThis will make license declarations simpler and less ambiguous for\npackage authors to create, end users to read and understand, and\ntools to programmatically process.\nThe PEP also:\n\nFormally specifies\na new License-File field, and defines how license files should be\nincluded in distributions,\nas already used by the Wheel and Setuptools projects.\nDeprecates the legacy License field\nand license :: classifiers.\nAdds and deprecates the corresponding keys\nin the pyproject.toml [project] table.\nProvides clear guidance for authors and\ntools converting legacy license metadata, adding license files and\nvalidating license expressions.\nDescribes a reference implementation,\nanalyzes numerous potential alternatives,\nincludes detailed examples,\nexplains user scenarios and\nsurveys license documentation\nin Python packaging and\nother ecosystems.\n\nThe changes in this PEP will update the\ncore metadata to version 2.4, modify the\nproject (source) metadata specification,\nand make minor additions to the source distribution (sdist),\nbuilt distribution (wheel) and\ninstalled project standards.\n"}, | |
| {"id": "640", "title": "Unused variable syntax", "authors": "Wouters", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "04-Oct-2020", "python_version": "3.10", "post_history": "19-Oct-2020", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0640/", "abstract": "\nAbstract\nThis PEP proposes new syntax for unused variables, providing a pseudo-name\nthat can be assigned to but not otherwise used. The assignment doesn't\nactually happen, and the value is discarded instead.\n"}, | |
| {"id": "641", "title": "Using an underscore in the version portion of Python 3.10 compatibility tags", "authors": "Cannon, Dower, Warsaw", "discussions_to": "https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "20-Oct-2020", "python_version": "3.10", "post_history": "21-Oct-2020", "resolution": "https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513/42", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0641/", "abstract": "\nAbstract\n\nNote\nThis PEP was rejected due to potential breakage in the community.\n\nUsing the tag system outlined in PEP 425 (primarily used for wheel\nfile names), each release of Python specifies compatibility tags\n(e.g. cp39, py39 for CPython 3.9). For CPython 3.10, this PEP\nproposes using 3_10 as the version portion of the tags\n(instead of 310).\n"}, | |
| {"id": "642", "title": "Explicit Pattern Syntax for Structural Pattern Matching", "authors": "Coghlan", "discussions_to": "python-dev@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "26-Sep-2020", "python_version": "3.10", "post_history": "31-Oct-2020, 08-Nov-2020, 03-Jan-2021", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3/", "requires": "634", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0642/", "abstract": "\nAbstract\nThis PEP covers an alternative syntax proposal for PEP 634's structural pattern\nmatching that requires explicit prefixes on all capture patterns and value\nconstraints. It also proposes a new dedicated syntax for instance attribute\npatterns that aligns more closely with the proposed mapping pattern syntax.\nWhile the result is necessarily more verbose than the proposed syntax in\nPEP 634, it is still significantly less verbose than the status quo.\nAs an example, the following match statement would extract \"host\" and \"port\"\ndetails from a 2 item sequence, a mapping with \"host\" and \"port\" keys, any\nobject with \"host\" and \"port\" attributes, or a \"host:port\" string, treating\nthe \"port\" as optional in the latter three cases:\nport = DEFAULT_PORT\nmatch expr:\n case [as host, as port]:\n pass\n case {\"host\" as host, \"port\" as port}:\n pass\n case {\"host\" as host}:\n pass\n case object{.host as host, .port as port}:\n pass\n case object{.host as host}:\n pass\n case str{} as addr:\n host, __, optional_port = addr.partition(\":\")\n if optional_port:\n port = optional_port\n case __ as m:\n raise TypeError(f\"Unknown address format: {m!r:.200}\")\nport = int(port)\n\n\nAt a high level, this PEP proposes to categorise the different available pattern\ntypes as follows:\n\nwildcard pattern: __\ngroup patterns: (PTRN)\n\nvalue constraint patterns:\nequality constraints: == EXPR\nidentity constraints: is EXPR\n\n\n\n\n\nstructural constraint patterns:\nsequence constraint patterns: [PTRN, as NAME, PTRN as NAME]\nmapping constraint patterns: {EXPR: PTRN, EXPR as NAME}\ninstance attribute constraint patterns:\nCLS{.NAME, .NAME: PTRN, .NAME == EXPR, .NAME as NAME}\nclass defined constraint patterns:\nCLS(PTRN, PTRN, **{.NAME, .NAME: PTRN, .NAME == EXPR, .NAME as NAME})\n\n\n\n\nOR patterns: PTRN | PTRN | PTRN\nAS patterns: PTRN as NAME (omitting the pattern implies __)\n\nThe intent of this approach is to:\n\nallow an initial form of pattern matching to be developed and released without\nneeding to decide up front on the best default options for handling bare names,\nattribute lookups, and literal values\nensure that pattern matching is defined explicitly at the Abstract Syntax Tree\nlevel, allowing the specifications of the semantics and the surface syntax for\npattern matching to be clearly separated\ndefine a clear and concise \"ducktyping\" syntax that could potentially be\nadopted in ordinary expressions as a way to more easily retrieve a tuple\ncontaining multiple attributes from the same object\n\nRelative to PEP 634, the proposal also deliberately eliminates any syntax that\n\"binds to the right\" without using the as keyword (using capture patterns\nin PEP 634's mapping patterns and class patterns) or binds to both the left and\nthe right in the same pattern (using PEP 634's capture patterns with AS patterns)\n"}, | |
| {"id": "643", "title": "Metadata for Package Source Distributions", "authors": "Moore", "discussions_to": "https://discuss.python.org/t/pep-643-metadata-for-package-source-distributions/5577", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "24-Oct-2020", "python_version": null, "post_history": "24-Oct-2020, 01-Nov-2020, 02-Nov-2020, 14-Nov-2020", "resolution": "https://discuss.python.org/t/pep-643-metadata-for-package-source-distributions/5577/53", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0643/", "abstract": "\nAbstract\nPython package metadata is stored in the distribution file in a standard\nformat, defined in the Core Metadata Specification. However, for\nsource distributions, while the format of the data is defined, there has\ntraditionally been a lot of inconsistency in what data is recorded in\nthe source distribution. See here\nfor a discussion of this issue.\nAs a result, metadata consumers are unable to rely on the data available\nfrom source distributions, and need to use the (costly) PEP 517 build\nmechanisms to extract medatata.\nThis PEP defines a standard that allows build backends to reliably store\npackage metadata in the source distribution, while still retaining the\nnecessary flexibility to handle metadata fields that have to be calculated\nat build time.\n"}, | |
| {"id": "644", "title": "Require OpenSSL 1.1.1 or newer", "authors": "Heimes", "discussions_to": "https://discuss.python.org/t/pep-644-require-openssl-1-1-or-newer/5584", "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Oct-2020", "python_version": "3.10", "post_history": "27-Oct-2020, 03-Mar-2021, 17-Mar-2021, 17-Apr-2021", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/INLCO2EZVQW7R7J2OL6HWVLVU3TQRAZV/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0644/", "abstract": "\nAbstract\nThis PEP proposes for CPython's standard library to support only OpenSSL\n1.1.1 LTS or newer. Support for OpenSSL versions past end-of-lifetime,\nincompatible forks, and other TLS libraries are dropped.\n"}, | |
| {"id": "645", "title": "Allow writing optional types as ``x?``", "authors": "Moss", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "25-Aug-2020", "python_version": null, "post_history": null, "resolution": "https://mail.python.org/archives/list/typing-sig@python.org/message/E75SPV6DDHLEEFSA5MBN5HUOQWDMUQJ2/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0645/", "abstract": "\nAbstract\nThis PEP proposes adding a ? operator for types to allow writing int? in place of Optional[int].\n"}, | |
| {"id": "646", "title": "Variadic Generics", "authors": "Mendoza, Rahtz, Srinivasan, Siles", "discussions_to": null, "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "16-Sep-2020", "python_version": "3.11", "post_history": "07-Oct-2020, 23-Dec-2020, 29-Dec-2020", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/OR5RKV7GAVSGLVH3JAGQ6OXFAXIP5XDX/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0646/", "abstract": "\nAbstract\nPEP 484 introduced TypeVar, enabling creation of generics parameterised\nwith a single type. In this PEP, we introduce TypeVarTuple, enabling parameterisation\nwith an arbitrary number of types - that is, a variadic type variable,\nenabling variadic generics. This enables a wide variety of use cases.\nIn particular, it allows the type of array-like structures\nin numerical computing libraries such as NumPy and TensorFlow to be\nparameterised with the array shape, enabling static type checkers\nto catch shape-related bugs in code that uses these libraries.\n"}, | |
| {"id": "647", "title": "User-Defined Type Guards", "authors": "Traut", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "07-Oct-2020", "python_version": "3.10", "post_history": "28-Dec-2020, 09-Apr-2021", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/2ME6F6YUVKHOQYKSHTVQQU5WD4CVAZU4/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0647/", "abstract": "\nAbstract\nThis PEP specifies a way for programs to influence conditional type narrowing\nemployed by a type checker based on runtime checks.\n"}, | |
| {"id": "648", "title": "Extensible customizations of the interpreter at startup", "authors": "Corchero", "discussions_to": "https://discuss.python.org/t/pep-648-extensible-customizations-of-the-interpreter-at-startup/6403", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "30-Dec-2020", "python_version": "3.11", "post_history": "16-Dec-2020, 18-Dec-2020", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0648/", "abstract": "\nAbstract\nThis PEP proposes supporting extensible customization of the interpreter by\nallowing users to install files that will be executed at startup.\n"}, | |
| {"id": "649", "title": "Deferred Evaluation Of Annotations Using Descriptors", "authors": "Hastings", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "typing", "created": "11-Jan-2021", "python_version": null, "post_history": "11-Jan-2021, 11-Apr-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0649/", "abstract": "\nAbstract\nAs of Python 3.9, Python supports two different behaviors\nfor annotations:\n\noriginal or \"stock\" Python semantics, in which annotations\nare evaluated at the time they are bound, and\nPEP 563 semantics, currently enabled per-module by\nfrom __future__ import annotations, in which annotations\nare converted back into strings and must be reparsed and\nexecuted by eval() to be used.\n\nOriginal Python semantics created a circular references problem\nfor static typing analysis. PEP 563 solved that problem-but\nits novel semantics introduced new problems, including its\nrestriction that annotations can only reference names at\nmodule-level scope.\nThis PEP proposes a third way that embodies the best of both\nprevious approaches. It solves the same circular reference\nproblems solved by PEP 563, while otherwise preserving Python's\noriginal annotation semantics, including allowing annotations\nto refer to local and class variables.\nIn this new approach, the code to generate the annotations\ndict is written to its own function which computes and returns\nthe annotations dict. Then, __annotations__ is a \"data\ndescriptor\" which calls this annotation function once and\nretains the result. This delays the evaluation of annotations\nexpressions until the annotations are examined, at which point\nall circular references have likely been resolved. And if\nthe annotations are never examined, the function is never\ncalled and the annotations are never computed.\nAnnotations defined using this PEP's semantics have the same\nvisibility into the symbol table as annotations under \"stock\"\nsemantics-any name visible to an annotation in Python 3.9\nis visible to an annotation under this PEP. In addition,\nannotations under this PEP can refer to names defined after\nthe annotation is defined, as long as the name is defined in\na scope visible to the annotation. Specifically, when this PEP\nis active:\n\nAn annotation can refer to a local variable defined in the\ncurrent function scope.\nAn annotation can refer to a local variable defined in an\nenclosing function scope.\nAn annotation can refer to a class variable defined in the\ncurrent class scope.\nAn annotation can refer to a global variable.\n\nAnd in all four of these cases, the variable referenced by\nthe annotation needn't be defined at the time the annotation\nis defined-it can be defined afterwards. The only restriction\nis that the name or variable be defined before the annotation\nis evaluated.\nIf accepted, these new semantics for annotations would initially\nbe gated behind from __future__ import co_annotations.\nHowever, these semantics would eventually be promoted to be\nPython's default behavior. Thus this PEP would supersede\nPEP 563, and PEP 563's behavior would be deprecated and\neventually removed.\n"}, | |
| {"id": "650", "title": "Specifying Installer Requirements for Python Projects", "authors": "Jayanthi, Ingram, Cannon", "discussions_to": "https://discuss.python.org/t/pep-650-specifying-installer-requirements-for-python-projects/6657", "status": "Withdrawn", "type": "Standards Track", "topic": "packaging", "created": "16-Jul-2020", "python_version": null, "post_history": "14-Jan-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0650/", "abstract": "\nAbstract\nPython package installers are not completely interoperable with each\nother. While pip is the most widely used installer and a de facto\nstandard, other installers such as Poetry or Pipenv are popular as\nwell due to offering unique features which are optimal for certain\nworkflows and not directly in line with how pip operates.\nWhile the abundance of installer options is good for end-users with\nspecific needs, the lack of interoperability between them makes it\nhard to support all potential installers. Specifically, the lack of a\nstandard requirements file for declaring dependencies means that each\ntool must be explicitly used in order to install dependencies\nspecified with their respective format. Otherwise tools must emit a\nrequirements file which leads to potential information loss for the\ninstaller as well as an added export step as part of a developer's\nworkflow.\nBy providing a standardized API that can be used to invoke a\ncompatible installer, we can solve this problem without needing to\nresolve individual concerns, unique requirements, and\nincompatibilities between different installers and their lock files.\nInstallers that implement the specification can be invoked in a\nuniform way, allowing users to use their installer of choice as if\nthey were invoking it directly.\n"}, | |
| {"id": "651", "title": "Robust Stack Overflow Handling", "authors": "Shannon", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "18-Jan-2021", "python_version": null, "post_history": "19-Jan-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0651/", "abstract": "\nAbstract\nThis PEP proposes that Python should treat machine stack overflow differently from runaway recursion.\nThis would allow programs to set the maximum recursion depth to fit their needs\nand provide additional safety guarantees.\nIf this PEP is accepted, then the following program will run safely to completion:\nsys.setrecursionlimit(1_000_000)\n\ndef f(n):\n if n:\n f(n-1)\n\nf(500_000)\n\n\nand the following program will raise a StackOverflow, without causing a VM crash:\nsys.setrecursionlimit(1_000_000)\n\nclass X:\n def __add__(self, other):\n return self + other\n\nX() + 1\n\n\n"}, | |
| {"id": "652", "title": "Maintaining the Stable ABI", "authors": "Viktorin", "discussions_to": "https://discuss.python.org/t/pre-pep-maintaining-the-stable-abi/6986/", "status": "Final", "type": "Standards Track", "topic": "", "created": "09-Feb-2021", "python_version": "3.10", "post_history": null, "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/IN4XMFLQJ6D6V67EXU27GV3QWSEHHNNH/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0652/", "abstract": "\nAbstract\nCPython's Limited C-API and Stable ABI, introduced in PEP 384,\nwill be formalized in a single definitive file, tested, and documented.\n"}, | |
| {"id": "653", "title": "Precise Semantics for Pattern Matching", "authors": "Shannon", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "", "created": "09-Feb-2021", "python_version": null, "post_history": "18-Feb-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0653/", "abstract": "\nAbstract\nThis PEP proposes a semantics for pattern matching that respects the general concept of PEP 634,\nbut is more precise, easier to reason about, and should be faster.\nThe object model will be extended with two special (dunder) attributes, __match_container__ and\n__match_class__, in addition to the __match_args__ attribute from PEP 634, to support pattern matching.\nBoth of these new attributes must be integers and __match_args__ is required to be a tuple of unique strings.\nWith this PEP:\n\nThe semantics of pattern matching will be clearer, so that patterns are easier to reason about.\nIt will be possible to implement pattern matching in a more efficient fashion.\nPattern matching will be more usable for complex classes, by allowing classes some more control over which patterns they match.\n\n"}, | |
| {"id": "654", "title": "Exception Groups and except*", "authors": "Katriel, Selivanov, GvR", "discussions_to": null, "status": "Accepted", "type": "Standards Track", "topic": "", "created": "22-Feb-2021", "python_version": "3.11", "post_history": "22-Feb-2021, 20-Mar-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0654/", "abstract": "\nAbstract\nThis document proposes language extensions that allow programs to raise and handle\nmultiple unrelated exceptions simultaneously:\n\nA new standard exception type, the ExceptionGroup, which represents a\ngroup of unrelated exceptions being propagated together.\nA new syntax except* for handling ExceptionGroups.\n\n"}, | |
| {"id": "655", "title": "Marking individual TypedDict items as required or potentially-missing", "authors": "Foster", "discussions_to": "https://mail.python.org/archives/list/typing-sig@python.org/thread/53XVOD5ZUKJ263MWA6AUPEA6J7LBBLNV/", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "30-Jan-2021", "python_version": "3.11", "post_history": "31-Jan-2021, 11-Feb-2021, 20-Feb-2021, 26-Feb-2021, 17-Jan-2022, 28-Jan-2022", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/AJEDNVC3FXM5QXNNW5CR4UCT4KI5XVUE/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0655/", "abstract": "\nAbstract\nPEP 589 defines notation\nfor declaring a TypedDict with all required keys and notation for defining\na TypedDict with all potentially-missing keys, however it\ndoes not provide a mechanism to declare some keys as required and others\nas potentially-missing. This PEP introduces two new notations:\nRequired[], which can be used on individual items of a\nTypedDict to mark them as required, and\nNotRequired[], which can be used on individual items\nto mark them as potentially-missing.\nThis PEP makes no Python grammar changes. Correct usage\nof required and potentially-missing keys of TypedDicts is intended to be\nenforced only by static type checkers and need not be enforced by\nPython itself at runtime.\n"}, | |
| {"id": "656", "title": "Platform Tag for Linux Distributions Using Musl", "authors": "Chung", "discussions_to": "https://discuss.python.org/t/7165", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "17-Mar-2021", "python_version": null, "post_history": "17-Mar-2021, 18-Apr-2021", "resolution": "https://discuss.python.org/t/7165/32", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0656/", "abstract": "\nAbstract\nThis PEP proposes a new platform tag series musllinux for\nbinary Python package distributions for a Python installation that\ndepends on musl on a Linux distribution. The tag works similarly to\nthe \"perennial manylinux\" platform tags specified in PEP 600, but\ntargeting platforms based on musl instead.\n"}, | |
| {"id": "657", "title": "Include Fine Grained Error Locations in Tracebacks", "authors": "Galindo, Taskaya, Askar", "discussions_to": "https://discuss.python.org/t/pep-657-include-fine-grained-error-locations-in-tracebacks/8629", "status": "Final", "type": "Standards Track", "topic": "", "created": "08-May-2021", "python_version": "3.11", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0657/", "abstract": "\nAbstract\nThis PEP proposes adding a mapping from each bytecode instruction to the start\nand end column offsets of the line that generated them as well as the end line\nnumber. This data will be used to improve tracebacks displayed by the CPython\ninterpreter in order to improve the debugging experience. The PEP also proposes\nadding APIs that allow other tools (such as coverage analysis tools, profilers,\ntracers, debuggers) to consume this information from code objects.\n"}, | |
| {"id": "658", "title": "Serve Distribution Metadata in the Simple Repository API", "authors": "Chung", "discussions_to": "https://discuss.python.org/t/8651", "status": "Accepted", "type": "Standards Track", "topic": "packaging", "created": "10-May-2021", "python_version": null, "post_history": "10-May-2021", "resolution": "https://discuss.python.org/t/8651/48", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0658/", "abstract": "\nAbstract\nThis PEP proposes adding an anchor tag to expose the METADATA file\nfrom distributions in the PEP 503 \"simple\" repository API. A\ndata-dist-info-metadata attribute is introduced to indicate that\nthe file from a given distribution can be independently fetched.\n"}, | |
| {"id": "659", "title": "Specializing Adaptive Interpreter", "authors": "Shannon", "discussions_to": null, "status": "Draft", "type": "Informational", "topic": "", "created": "13-Apr-2021", "python_version": null, "post_history": "11-May-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0659/", "abstract": "\nAbstract\nIn order to perform well, virtual machines for dynamic languages must\nspecialize the code that they execute to the types and values in the\nprogram being run. This specialization is often associated with \"JIT\"\ncompilers, but is beneficial even without machine code generation.\nA specializing, adaptive interpreter is one that speculatively specializes\non the types or values it is currently operating on, and adapts to changes\nin those types and values.\nSpecialization gives us improved performance, and adaptation allows the\ninterpreter to rapidly change when the pattern of usage in a program alters,\nlimiting the amount of additional work caused by mis-specialization.\nThis PEP proposes using a specializing, adaptive interpreter that specializes\ncode aggressively, but over a very small region, and is able to adjust to\nmis-specialization rapidly and at low cost.\nAdding a specializing, adaptive interpreter to CPython will bring significant\nperformance improvements. It is hard to come up with meaningful numbers,\nas it depends very much on the benchmarks and on work that has not yet happened.\nExtensive experimentation suggests speedups of up to 50%.\nEven if the speedup were only 25%, this would still be a worthwhile enhancement.\n"}, | |
| {"id": "660", "title": "Editable installs for pyproject.toml based builds (wheel based)", "authors": "Holth, Bidoul", "discussions_to": "https://discuss.python.org/t/draft-pep-editable-installs-for-pep-517-style-build-backends/8510", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "30-Mar-2021", "python_version": null, "post_history": null, "resolution": "https://discuss.python.org/t/pronouncement-on-peps-660-and-662-editable-installs/9450", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0660/", "abstract": "\nAbstract\nThis document describes a PEP 517 style method for the installation of packages\nin editable mode.\n"}, | |
| {"id": "661", "title": "Sentinel Values", "authors": "Einat", "discussions_to": "https://discuss.python.org/t/pep-661-sentinel-values/9126", "status": "Draft", "type": "Standards Track", "topic": "", "created": "06-Jun-2021", "python_version": null, "post_history": "06-Jun-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0661/", "abstract": "\nAbstract\nUnique placeholder values, commonly known as \"sentinel values\", are common in\nprogramming. They have many uses, such as for:\n\nDefault values for function arguments, for when a value was not given:def foo(value=None):\n ...\n\n\n\nReturn values from functions when something is not found or unavailable:>>> \"abc\".find(\"d\")\n-1\n\n\n\nMissing data, such as NULL in relational databases or \"N/A\" (\"not\navailable\") in spreadsheets\n\nPython has the special value None, which is intended to be used as such\na sentinel value in most cases. However, sometimes an alternative sentinel\nvalue is needed, usually when it needs to be distinct from None. These\ncases are common enough that several idioms for implementing such sentinels\nhave arisen over the years, but uncommon enough that there hasn't been a\nclear need for standardization. However, the common implementations,\nincluding some in the stdlib, suffer from several significant drawbacks.\nThis PEP proposes adding a utility for defining sentinel values, to be used\nin the stdlib and made publicly available as part of the stdlib.\nNote: Changing all existing sentinels in the stdlib to be implemented this\nway is not deemed necessary, and whether to do so is left to the discretion\nof the maintainers.\n"}, | |
| {"id": "662", "title": "Editable installs via virtual wheels", "authors": "G\u00e1bor", "discussions_to": "https://discuss.python.org/t/discuss-tbd-editable-installs-by-gaborbernat/9071", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "28-May-2021", "python_version": null, "post_history": null, "resolution": "https://discuss.python.org/t/pronouncement-on-peps-660-and-662-editable-installs/9450", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0662/", "abstract": "\nAbstract\nThis document describes extensions to the build backend and frontend\ncommunication (as introduced by PEP 517) to allow projects to be installed in\neditable mode by introducing virtual wheels.\n"}, | |
| {"id": "663", "title": "Standardizing Enum str(), repr(), and format() behaviors", "authors": "Furman", "discussions_to": "python-dev@python.org", "status": "Rejected", "type": "Informational", "topic": "", "created": "30-Jun-2021", "python_version": "3.11", "post_history": "20-Jul-2021, 02-Nov-2021", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/RN3WCRZSTQR55DOHJTZ2KIO6CZPJPCU7/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0663/", "abstract": "\nAbstract\nUpdate the repr(), str(), and format() of the various Enum types\nto better match their intended purpose. For example, IntEnum will have\nits str() change to match its format(), while a user-mixed int-enum\nwill have its format() match its str(). In all cases, an enum's\nstr() and format() will be the same (unless the user overrides\nformat()).\nAdd a global enum decorator which changes the str() and repr() (and\nformat()) of the decorated enum to be a valid global reference: i.e.\nre.IGNORECASE instead of <RegexFlag.IGNORECASE: 2>.\n"}, | |
| {"id": "664", "title": "Python 3.11 Release Schedule", "authors": "Salgado", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "release", "created": "12-Jul-2021", "python_version": "3.11", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0664/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.11. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "665", "title": "A file format to list Python dependencies for reproducibility of an application", "authors": "Cannon, Gedam, Chung", "discussions_to": "https://discuss.python.org/t/9911", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "29-Jul-2021", "python_version": null, "post_history": "29-Jul-2021, 03-Nov-2021, 25-Nov-2021", "resolution": "https://discuss.python.org/t/pep-665-take-2-a-file-format-to-list-python-dependencies-for-reproducibility-of-an-application/11736/140", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0665/", "abstract": "\nAbstract\nThis PEP specifies a file format to specify the list of Python package\ninstallation requirements for an application, and the relation between\nthe specified requirements. The list of requirements is considered\nexhaustive for the installation target, and thus not requiring any\ninformation beyond the platform being installed for, and the file\nitself. The file format is flexible enough to allow installing the\nrequirements across different platforms, which allows for\nreproducibility on multiple platforms from the same file.\n"}, | |
| {"id": "666", "title": "Reject Foolish Indentation", "authors": "Creighton", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "03-Dec-2001", "python_version": "2.2", "post_history": "05-Dec-2001", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0666/", "abstract": "\nAbstract\nEverybody agrees that mixing tabs and spaces is a bad idea. Some\npeople want more than this. I propose that we let people define\nwhatever Python behaviour they want, so it will only run the way\nthey like it, and will not run the way they don't like it. We\nwill do this with a command line switch. Programs that aren't\nformatted the way the programmer wants things will raise\nIndentationError.\n\npython -TNone will refuse to run when there are any tabs.\npython -Tn will refuse to run when tabs are not exactly n spaces\npython -TOnly will refuse to run when blocks are indented by anything\nother than tabs\n\nPeople who mix tabs and spaces, naturally, will find that their\nprograms do not run. Alas, we haven't found a way to give them an\nelectric shock as from a cattle prod remotely. (Though if somebody\nfinds out a way to do this, I will be pleased to add this option to\nthe PEP.)\n"}, | |
| {"id": "667", "title": "Consistent views of namespaces", "authors": "Shannon", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "", "created": "30-Jul-2021", "python_version": null, "post_history": "20-Aug-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0667/", "abstract": "\nAbstract\nIn early versions of Python all namespaces, whether in functions,\nclasses or modules, were all implemented the same way: as a dictionary.\nFor performance reasons, the implementation of function namespaces was\nchanged. Unfortunately this meant that accessing these namespaces through\nlocals() and frame.f_locals ceased to be consistent and some\nodd bugs crept in over the years as threads, generators and coroutines\nwere added.\nThis PEP proposes making these namespaces consistent once more.\nModifications to frame.f_locals will always be visible in\nthe underlying variables. Modifications to local variables will\nimmediately be visible in frame.f_locals, and they will be\nconsistent regardless of threading or coroutines.\nThe locals() function will act the same as it does now for class\nand modules scopes. For function scopes it will return an instantaneous\nsnapshot of the underlying frame.f_locals.\n"}, | |
| {"id": "668", "title": "Marking Python base environments as \u201cexternally managed\u201d", "authors": "Thomas, Klose, La\u00edns, Stufft, Chung, Rivera, Hashman, Gedam", "discussions_to": "https://discuss.python.org/t/10302", "status": "Accepted", "type": "Standards Track", "topic": "packaging", "created": "18-May-2021", "python_version": null, "post_history": "28-May-2021", "resolution": "https://discuss.python.org/t/10302/44", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0668/", "abstract": "\nAbstract\nA long-standing practical problem for Python users has been conflicts\nbetween OS package managers and Python-specific package management\ntools like pip. These conflicts include both Python-level API\nincompatibilities and conflicts over file ownership.\nHistorically, Python-specific package management tools have defaulted\nto installing packages into an implicit global context. With the\nstandardization and popularity of virtual environments, a better\nsolution for most (but not all) use cases is to use Python-specific\npackage management tools only within a virtual environment.\nThis PEP proposes a mechanism for a Python installation to communicate\nto tools like pip that its global package installation context is\nmanaged by some means external to Python, such as an OS package\nmanager. It specifies that Python-specific package management tools\nshould neither install nor remove packages into the interpreter's\nglobal context, by default, and should instead guide the end user\ntowards using a virtual environment.\nIt also standardizes an interpretation of the sysconfig schemes so\nthat, if a Python-specific package manager is about to install a\npackage in an interpreter-wide context, it can do so in a manner that\nwill avoid conflicting with the external package manager and reduces\nthe risk of breaking software shipped by the external package manager.\n"}, | |
| {"id": "669", "title": "Low Impact Monitoring for CPython", "authors": "Shannon", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "", "created": "18-Aug-2021", "python_version": null, "post_history": "07-Dec-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0669/", "abstract": "\nAbstract\nUsing a profiler or debugger in CPython can have a severe impact on\nperformance. Slowdowns by an order of magnitude are common.\nThis PEP proposes an API for monitoring Python programs running\non CPython that will enable monitoring at low cost.\nAlthough this PEP does not specify an implementation, it is expected that\nit will be implemented using the quickening step of\nPEP 659.\nA sys.monitoring namespace will be added, which will contain\nthe relevant functions and enum.\n"}, | |
| {"id": "670", "title": "Convert macros to functions in the Python C API", "authors": "Aasland, Stinner", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Oct-2021", "python_version": "3.11", "post_history": "`20-Oct-2021 <https://mail.python.org/archives/list/python-dev@python.org/thread/2GN646CGWGTO6ZHHU7JTA5XWDF4ULM77/>`__, `08-Feb-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/IJ3IBVY3JDPROKX55YNDT6XZTVTTPGOP/>`__, `22-Feb-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/VM6I3UHVMME6QRSUOYLK6N2OZHP454W6/>`__", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/QQFCJ7LR36RUZSC3WI6WZZMQVQ3ZI4MS/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0670/", "abstract": "\nAbstract\nMacros in the C API will be converted to static inline functions or\nregular functions. This will help avoid macro pitfalls in C/C++, and\nmake the functions usable from other programming languages.\nTo avoid compiler warnings, function arguments of pointer types\nwill be cast to appropriate types using additional macros.\nThe cast will not be done in the limited C API version 3.11:\nusers who opt in to the new limited API may need to add casts to\nthe exact expected type.\nTo avoid introducing incompatible changes, macros which can be used as\nl-value in an assignment will not be converted.\n"}, | |
| {"id": "671", "title": "Syntax for late-bound function argument defaults", "authors": "Angelico", "discussions_to": "https://mail.python.org/archives/list/python-ideas@python.org/thread/UVOQEK7IRFSCBOH734T5GFJOEJXFCR6A/", "status": "Draft", "type": "Standards Track", "topic": "", "created": "24-Oct-2021", "python_version": "3.12", "post_history": "`24-Oct-2021 <https://mail.python.org/archives/list/python-ideas@python.org/thread/KR2TMLPFR7NHDZCDOS6VTNWDKZQQJN3V/>`__, `01-Dec-2021 <https://mail.python.org/archives/list/python-ideas@python.org/thread/UVOQEK7IRFSCBOH734T5GFJOEJXFCR6A/>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0671/", "abstract": "\nAbstract\nFunction parameters can have default values which are calculated during\nfunction definition and saved. This proposal introduces a new form of\nargument default, defined by an expression to be evaluated at function\ncall time.\n"}, | |
| {"id": "672", "title": "Unicode-related Security Considerations for Python", "authors": "Viktorin", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "01-Nov-2021", "python_version": null, "post_history": "01-Nov-2021", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0672/", "abstract": "\nIntroduction\nUnicode is a system for handling all kinds of written language.\nIt aims to allow any character from any human language to be\nused. Python code may consist of almost all valid Unicode characters.\nWhile this allows programmers from all around the world to express themselves,\nit also allows writing code that is potentially confusing to readers.\nIt is possible to misuse Python's Unicode-related features to write code that\nappears to do something else than what it does.\nEvildoers could take advantage of this to trick code reviewers into\naccepting malicious code.\nThe possible issues generally can't be solved in Python itself without\nexcessive restrictions of the language.\nThey should be solved in code editors and review tools\n(such as diff displays), by enforcing project-specific policies,\nand by raising awareness of individual programmers.\nThis document purposefully does not give any solutions\nor recommendations: it is rather a list of things to keep in mind.\nThis document is specific to Python.\nFor general security considerations in Unicode text, see [tr36] and [tr39].\n"}, | |
| {"id": "673", "title": "Self Type", "authors": "Srinivasan, Hilton-Balfe", "discussions_to": "typing-sig@python.org", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "10-Nov-2021", "python_version": "3.11", "post_history": "17-Nov-2021", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/J7BWL5KWOPQQK5KFWKENVLXW6UGSPTGI/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0673/", "abstract": "\nAbstract\nThis PEP introduces a simple and intuitive way to annotate methods that return\nan instance of their class. This behaves the same as the TypeVar-based\napproach specified in PEP 484\nbut is more concise and easier to follow.\n"}, | |
| {"id": "674", "title": "Disallow using macros as l-values", "authors": "Stinner", "discussions_to": null, "status": "Draft", "type": "Standards Track", "topic": "", "created": "30-Nov-2021", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0674/", "abstract": "\nAbstract\nDisallow using macros as l-values. For example,\nPy_TYPE(obj) = new_type now fails with a compiler error.\nIn practice, the majority of affected projects only have to make two\nchanges:\n\nReplace Py_TYPE(obj) = new_type\nwith Py_SET_TYPE(obj, new_type).\nReplace Py_SIZE(obj) = new_size\nwith Py_SET_SIZE(obj, new_size).\n\n"}, | |
| {"id": "675", "title": "Arbitrary Literal String Type", "authors": "Srinivasan, Bleaney", "discussions_to": "https://mail.python.org/archives/list/typing-sig@python.org/thread/VB74EHNM4RODDFM64NEEEBJQVAUAWIAW/", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "30-Nov-2021", "python_version": "3.11", "post_history": "07-Feb-2022", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/XEOOSSPNYPGZ5NXOJFPLXG2BTN7EVRT5/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0675/", "abstract": "\nAbstract\nThere is currently no way to specify, using type annotations, that a\nfunction parameter can be of any literal string type. We have to\nspecify a precise literal string type, such as\nLiteral[\"foo\"]. This PEP introduces a supertype of literal string\ntypes: LiteralString. This allows a function to accept arbitrary\nliteral string types, such as Literal[\"foo\"] or\nLiteral[\"bar\"].\n"}, | |
| {"id": "676", "title": "PEP Infrastructure Process", "authors": "Turner", "discussions_to": "https://discuss.python.org/t/10774", "status": "Active", "type": "Process", "topic": "", "created": "01-Nov-2021", "python_version": null, "post_history": "23-Sep-2021, 30-Nov-2021", "resolution": "https://discuss.python.org/t/10774/99", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0676/", "abstract": "\nAbstract\nThis PEP addresses the infrastructure around rendering PEP files from\nreStructuredText files to HTML webpages. We aim to specify a self-contained\nand maintainable solution for PEP readers, authors, and editors.\n"}, | |
| {"id": "677", "title": "Callable Type Syntax", "authors": "Troxler, Srinivasan", "discussions_to": "python-dev@python.org", "status": "Rejected", "type": "Standards Track", "topic": "typing", "created": "13-Dec-2021", "python_version": "3.11", "post_history": "16-Dec-2021", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/NHCLHCU2XCWTBGF732WESMN42YYVKOXB/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0677/", "abstract": "\nAbstract\nThis PEP introduces a concise and friendly syntax for callable types,\nsupporting the same functionality as typing.Callable but with an\narrow syntax inspired by the syntax for typed function\nsignatures. This allows types like Callable[[int, str], bool] to\nbe written as (int, str) -> bool.\nThe proposed syntax supports all the functionality provided by\ntyping.Callable and typing.Concatenate, and is intended to\nwork as a drop-in replacement.\n"}, | |
| {"id": "678", "title": "Enriching Exceptions with Notes", "authors": "Hatfield-Dodds", "discussions_to": "https://discuss.python.org/t/pep-678-enriching-exceptions-with-notes/13374", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "20-Dec-2021", "python_version": "3.11", "post_history": "27-Jan-2022", "resolution": "https://discuss.python.org/t/pep-678-enriching-exceptions-with-notes/13374/100", "requires": "654", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0678/", "abstract": "\nAbstract\nException objects are typically initialized with a message that describes the\nerror which has occurred. Because further information may be available when\nthe exception is caught and re-raised, or included in an ExceptionGroup,\nthis PEP proposes to add BaseException.add_note(note), a\n.__notes__ attribute holding a list of notes so added, and to\nupdate the builtin traceback formatting code to include notes in the formatted\ntraceback following the exception string.\nThis is particularly useful in relation to PEP 654 ExceptionGroups,\nwhich make previous workarounds ineffective or confusing. Use cases have been\nidentified in the standard library, Hypothesis and cattrs packages, and\ncommon code patterns with retries.\n"}, | |
| {"id": "679", "title": "Allow parentheses in assert statements", "authors": "Salgado", "discussions_to": "https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003", "status": "Draft", "type": "Standards Track", "topic": "", "created": "07-Jan-2022", "python_version": "3.12", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0679/", "abstract": "\nAbstract\nThis PEP proposes to allow parentheses surrounding the two-argument form of\nassert statements. This will cause the interpreter to reinterpret what before\nwould have been an assert with a two-element tuple that will always be True\n(assert (expression, message)) to an assert statement with a subject and a\nfailure message, equivalent to the statement with the parentheses removed\n(assert expression, message).\n"}, | |
| {"id": "680", "title": "tomllib: Support for Parsing TOML in the Standard Library", "authors": "Hukkinen", "discussions_to": "https://discuss.python.org/t/13040", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "01-Jan-2022", "python_version": "3.11", "post_history": "11-Jan-2022", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/thread/3AHGWYY562HHO55L4Z2OVYUFZP5W73IS/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0680/", "abstract": "\nAbstract\nThis PEP proposes adding the tomllib module to the standard library for\nparsing TOML (Tom's Obvious Minimal Language,\nhttps://toml.io).\n"}, | |
| {"id": "681", "title": "Data Class Transforms", "authors": "De Bonte, Traut", "discussions_to": "https://mail.python.org/archives/list/typing-sig@python.org/thread/EAALIHA3XEDFDNG2NRXTI3ERFPAD65Z4/", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "02-Dec-2021", "python_version": "3.11", "post_history": "`24-Apr-2021 <https://mail.python.org/archives/list/typing-sig@python.org/thread/TXL5LEHYX5ZJAZPZ7YHZU7MVFXMVUVWL/>`__, `13-Dec-2021 <https://mail.python.org/archives/list/typing-sig@python.org/thread/EAALIHA3XEDFDNG2NRXTI3ERFPAD65Z4/>`__, `22-Feb-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/BW6CB6URC4BCN54QSG2STINU2M7V4TQQ/>`__", "resolution": "https://mail.python.org/archives/list/python-dev@python.org/message/R4A2IYLGFHKFDYJPSDA5NFJ6N7KRPJ6D/", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0681/", "abstract": "\nAbstract\nPEP 557 introduced the dataclass to the Python stdlib. Several popular\nlibraries have behaviors that are similar to dataclasses, but these\nbehaviors cannot be described using standard type annotations. Such\nprojects include attrs, pydantic, and object relational mapper (ORM)\npackages such as SQLAlchemy and Django.\nMost type checkers, linters and language servers have full support for\ndataclasses. This proposal aims to generalize this functionality and\nprovide a way for third-party libraries to indicate that certain\ndecorator functions, classes, and metaclasses provide behaviors\nsimilar to dataclasses.\nThese behaviors include:\n\nSynthesizing an __init__ method based on declared\ndata fields.\nOptionally synthesizing __eq__, __ne__, __lt__,\n__le__, __gt__ and __ge__ methods.\nSupporting \"frozen\" classes, a way to enforce immutability during\nstatic type checking.\nSupporting \"field specifiers\", which describe attributes of\nindividual fields that a static type checker must be aware of,\nsuch as whether a default value is provided for the field.\n\nThe full behavior of the stdlib dataclass is described in the Python\ndocumentation.\nThis proposal does not affect CPython directly except for the addition\nof a dataclass_transform decorator in typing.py.\n"}, | |
| {"id": "682", "title": "Format Specifier for Signed Zero", "authors": "Belmonte", "discussions_to": "https://discuss.python.org/t/pep-682-format-specifier-for-signed-zero/13596", "status": "Final", "type": "Standards Track", "topic": "", "created": "29-Jan-2022", "python_version": "3.11", "post_history": "08-Feb-2022", "resolution": "https://discuss.python.org/t/accepting-pep-682-format-specifier-for-signed-zero/14088", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0682/", "abstract": "\nAbstract\nThough float and Decimal types can represent signed zero, in many\nfields of mathematics negative zero is surprising or unwanted - especially\nin the context of displaying an (often rounded) numerical result. This PEP\nproposes an extension to the string format specification allowing negative\nzero to be normalized to positive zero.\n"}, | |
| {"id": "683", "title": "Immortal Objects, Using a Fixed Refcount", "authors": "Snow, Elizondo", "discussions_to": "https://discuss.python.org/t/18183", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "10-Feb-2022", "python_version": "3.12", "post_history": "`16-Feb-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/TPLEYDCXFQ4AMTW6F6OQFINSIFYBRFCR/>`__, `19-Feb-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/KDAR6CCMPOX36GQJUDWHQBKRD5USNV3B/>`__, `28-Feb-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/MI22URMVKC63OFMZTALHFZKAKVGAT4UF/>`__, `12-Aug-2022 <https://discuss.python.org/t/18183>`__,", "resolution": "https://discuss.python.org/t/18183/26", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0683/", "abstract": "\nAbstract\nCurrently the CPython runtime maintains a\nsmall amount of mutable state in the\nallocated memory of each object. Because of this, otherwise immutable\nobjects are actually mutable. This can have a large negative impact\non CPU and memory performance, especially for approaches to increasing\nPython's scalability.\nThis proposal mandates that, internally, CPython will support marking\nan object as one for which that runtime state will no longer change.\nConsequently, such an object's refcount will never reach 0, and thus\nthe object will never be cleaned up (except when the runtime knows\nit's safe to do so, like during runtime finalization).\nWe call these objects \"immortal\". (Normally, only a relatively small\nnumber of internal objects will ever be immortal.)\nThe fundamental improvement here is that now an object\ncan be truly immutable.\n\nScope\nObject immortality is meant to be an internal-only feature, so this\nproposal does not include any changes to public API or behavior\n(with one exception). As usual, we may still add some private\n(yet publicly accessible) API to do things like immortalize an object\nor tell if one is immortal. Any effort to expose this feature to users\nwould need to be proposed separately.\nThere is one exception to \"no change in behavior\": refcounting semantics\nfor immortal objects will differ in some cases from user expectations.\nThis exception, and the solution, are discussed below.\nMost of this PEP focuses on an internal implementation that satisfies\nthe above mandate. However, those implementation details are not meant\nto be strictly proscriptive. Instead, at the least they are included\nto help illustrate the technical considerations required by the mandate.\nThe actual implementation may deviate somewhat as long as it satisfies\nthe constraints outlined below. Furthermore, the acceptability of any\nspecific implementation detail described below does not depend on\nthe status of this PEP, unless explicitly specified.\nFor example, the particular details of:\n\nhow to mark something as immortal\nhow to recognize something as immortal\nwhich subset of functionally immortal objects are marked as immortal\nwhich memory-management activities are skipped or modified for immortal objects\n\nare not only CPython-specific but are also private implementation\ndetails that are expected to change in subsequent versions.\n\n\nImplementation Summary\nHere's a high-level look at the implementation:\nIf an object's refcount matches a very specific value (defined below)\nthen that object is treated as immortal. The CPython C-API and runtime\nwill not modify the refcount (or other runtime state) of an immortal\nobject. The runtime will now be explicitly responsible for deallocating\nall immortal objects during finalization, unless statically allocated.\n(See Object Cleanup below.)\nAside from the change to refcounting semantics, there is one other\npossible negative impact to consider. The threshold for an \"acceptable\"\nperformance penalty for immortal objects is 2% (the consensus at the\n2022 Language Summit). A naive implementation of the approach described\nbelow makes CPython roughly 4% slower. However, the implementation\nis ~performance-neutral~ once known mitigations are applied.\nTODO: Update the performance impact for the latest branch\n(both for GCC and for clang).\n\n"}, | |
| {"id": "684", "title": "A Per-Interpreter GIL", "authors": "Snow", "discussions_to": "https://discuss.python.org/t/pep-684-a-per-interpreter-gil/19583", "status": "Draft", "type": "Standards Track", "topic": "", "created": "08-Mar-2022", "python_version": "3.12", "post_history": "`08-Mar-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/CF7B7FMACFYDAHU6NPBEVEY6TOSGICXU/>`__, `29-Sep-2022 <https://discuss.python.org/t/pep-684-a-per-interpreter-gil/19583>`__,", "resolution": "", "requires": "683", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0684/", "abstract": "\nAbstract\nSince Python 1.5 (1997), CPython users can run multiple interpreters\nin the same process. However, interpreters in the same process\nhave always shared a significant\namount of global state. This is a source of bugs, with a growing\nimpact as more and more people use the feature. Furthermore,\nsufficient isolation would facilitate true multi-core parallelism,\nwhere interpreters no longer share the GIL. The changes outlined in\nthis proposal will result in that level of interpreter isolation.\n"}, | |
| {"id": "685", "title": "Comparison of extra names for optional distribution dependencies", "authors": "Cannon", "discussions_to": "https://discuss.python.org/t/14141", "status": "Accepted", "type": "Standards Track", "topic": "packaging", "created": "08-Mar-2022", "python_version": null, "post_history": "`08-Mar-2022 <https://discuss.python.org/t/14141>`__", "resolution": "https://discuss.python.org/t/pep-685-comparison-of-extra-names-for-optional-distribution-dependencies/14141/55", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0685/", "abstract": "\nAbstract\nThis PEP specifies how to normalize distribution extra\nnames when performing comparisons.\nThis prevents tools from either failing to find an extra name, or\naccidentally matching against an unexpected name.\n"}, | |
| {"id": "686", "title": "Make UTF-8 mode default", "authors": "Inada", "discussions_to": "https://discuss.python.org/t/14737", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "18-Mar-2022", "python_version": "3.15", "post_history": "`18-Mar-2022 <https://discuss.python.org/t/14435>`__, `31-Mar-2022 <https://discuss.python.org/t/14737>`__", "resolution": "https://discuss.python.org/t/14737/9", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0686/", "abstract": "\nAbstract\nThis PEP proposes enabling UTF-8 mode by default.\nWith this change, Python consistently uses UTF-8 for default encoding of\nfiles, stdio, and pipes.\n"}, | |
| {"id": "687", "title": "Isolating modules in the standard library", "authors": "Aasland, Viktorin", "discussions_to": "https://discuss.python.org/t/14824", "status": "Accepted", "type": "Standards Track", "topic": "", "created": "04-Apr-2022", "python_version": "3.12", "post_history": "`04-Apr-2022 <https://discuss.python.org/t/14824>`__, `11-Apr-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/B3HYQIE4Z5WBJCC3FUZJZHXLM32I4BZA/>`__", "resolution": "https://discuss.python.org/t/14824/4", "requires": "489, 573, 630", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0687/", "abstract": "\nAbstract\nExtensions in the standard library will be converted to multi-phase\ninitialization (PEP 489) and where possible, all state will be\nstored on module objects rather than in process-global variables.\n"}, | |
| {"id": "688", "title": "Making the buffer protocol accessible in Python", "authors": "Zijlstra", "discussions_to": "https://discuss.python.org/t/19756", "status": "Draft", "type": "Standards Track", "topic": "typing", "created": "23-Apr-2022", "python_version": "3.12", "post_history": "`23-Apr-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/CX7GPSIYQEL23RXMYL66GAKGP4RLUD7P/>`__, `25-Apr-2022 <https://discuss.python.org/t/15265>`__, `06-Oct-2022 <https://discuss.python.org/t/19756>`__, `26-Oct-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/XH5ZK2MSZIQLL62PYZ6I5532SQKKVCBL/>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0688/", "abstract": "\nAbstract\nThis PEP proposes a Python-level API for the buffer protocol,\nwhich is currently accessible only to C code. This allows type\ncheckers to evaluate whether objects implement the protocol.\n"}, | |
| {"id": "689", "title": "Unstable C API tier", "authors": "Viktorin", "discussions_to": "https://discuss.python.org/t/pep-689-unstable-c-api-tier/20452", "status": "Draft", "type": "Standards Track", "topic": "", "created": "22-Apr-2022", "python_version": "3.12", "post_history": "`27-Apr-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/PQXSP7E2B6KNXTJ2AERWMKKX42YP5D6O/>`__, `25-Aug-2022 <https://discuss.python.org/t/c-api-what-should-the-leading-underscore-py-mean/18486>`__, `27-Oct-2022 <https://discuss.python.org/t/pep-689-unstable-c-api-tier/20452>`__,", "resolution": null, "requires": "523", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0689/", "abstract": "\nAbstract\nSome functions and types of the C-API are designated unstable,\nmeaning that they will not change in patch (bugfix/security) releases,\nbut may change between minor releases (e.g. between 3.11 and 3.12) without\ndeprecation warnings.\nAny C API with a leading underscore is designated internal, meaning that it\nmay change or disappear without any notice.\n"}, | |
| {"id": "690", "title": "Lazy Imports", "authors": "M\u00e9ndez Bravo, Meyer", "discussions_to": "https://discuss.python.org/t/pep-690-lazy-imports/15474", "status": "Draft", "type": "Standards Track", "topic": "", "created": "29-Apr-2022", "python_version": "3.12", "post_history": "`03-May-2022 <https://discuss.python.org/t/pep-690-lazy-imports/15474>`__, `03-May-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/IHOSWMIBKCXVB46FI7NGOC2F34RUYZ5Z/>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0690/", "abstract": "\nAbstract\nThis PEP proposes a feature to transparently defer the finding and execution of\nimported modules until the moment when an imported object is first used. Since\nPython programs commonly import many more modules than a single invocation of\nthe program is likely to use in practice, lazy imports can greatly reduce the\noverall number of modules loaded, improving startup time and memory usage. Lazy\nimports also mostly eliminate the risk of import cycles.\n"}, | |
| {"id": "691", "title": "JSON-based Simple API for Python Package Indexes", "authors": "Stufft, Gedam, Lees, Ingram", "discussions_to": "https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553", "status": "Accepted", "type": "Standards Track", "topic": "packaging", "created": "04-May-2022", "python_version": null, "post_history": "`05-May-2022 <https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553>`__", "resolution": "https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553/70", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0691/", "abstract": "\nAbstract\nThe \"Simple Repository API\" that was defined in PEP 503 (and was in use much\nlonger than that) has served us reasonably well for a very long time. However,\nthe reliance on using HTML as the data exchange mechanism has several\nshortcomings.\nThere are two major issues with an HTML-based API:\n\nWhile HTML5 is a standard, it's an incredibly complex standard and ensuring\ncompletely correct parsing of it involves complex logic that does not\ncurrently exist within the Python standard library (nor the standard library\nof many other languages).This means that to actually accept everything that is technically valid, tools\nhave to pull in large dependencies or they have to rely on the standard library's\nhtml.parser library, which is lighter weight but potentially doesn't\nfully support HTML5.\n\nHTML5 is primarily designed as a markup language to present documents for human\nconsumption. Our use of it is driven largely for historical and accidental\nreasons, and it's unlikely anyone would design an API that relied on it if\nthey were starting from scratch.The primary issue with using a markup format designed for human consumption\nis that there's not a great way to actually encode data within HTML. We've\ngotten around this by limiting the data we put in this API and being creative\nwith how we can cram data into the API (for instance, hashes are embedded as\nURL fragments, adding the data-yanked attribute in PEP 592).\n\n\nPEP 503 was largely an attempt to standardize what was already in use, so it\ndid not propose any large changes to the API.\nIn the intervening years, we've regularly talked about an \"API V2\" that would\nre-envision the entire API of PyPI. However, due to limited time constraints,\nthat effort has not gained much, if any, traction beyond people thinking that\nit would be nice to do.\nThis PEP attempts to take a different route. It doesn't fundamentally change\nthe overall API structure, but instead specifies a new serialization of the\nexisting data contained in existing PEP 503 responses in a format that is\neasier for software to parse rather than using a human centric document format.\n"}, | |
| {"id": "692", "title": "Using TypedDict for more precise \\*\\*kwargs typing", "authors": "Magiera", "discussions_to": "https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314", "status": "Draft", "type": "Standards Track", "topic": "typing", "created": "29-May-2022", "python_version": "3.12", "post_history": "`29-May-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/U42MJE6QZYWPVIFHJIGIT7OE52ZGIQV3/>`__, `12-Jul-2022 <https://mail.python.org/archives/list/python-dev@python.org/thread/PLCNW2XR4OOKAKHEZQM7R2AYVYUXPZGW/>`__, `12-Jul-2022 <https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314>`__,", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0692/", "abstract": "\nAbstract\nCurrently **kwargs can be type hinted as long as all of the keyword\narguments specified by them are of the same type. However, that behaviour can\nbe very limiting. Therefore, in this PEP we propose a new way to enable more\nprecise **kwargs typing. The new approach revolves around using\nTypedDict to type **kwargs that comprise keyword arguments of different\ntypes. It also involves introducing a grammar change and a new dunder\n__typing_unpack__.\n"}, | |
| {"id": "693", "title": "Python 3.12 Release Schedule", "authors": "Wouters", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "release", "created": "24-May-2022", "python_version": "3.12", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0693/", "abstract": "\nAbstract\nThis document describes the development and release schedule for\nPython 3.12. The schedule primarily concerns itself with PEP-sized\nitems.\n"}, | |
| {"id": "694", "title": "Upload 2.0 API for Python Package Repositories", "authors": "Stufft", "discussions_to": "https://discuss.python.org/t/pep-694-upload-2-0-api-for-python-package-repositories/16879", "status": "Draft", "type": "Standards Track", "topic": "packaging", "created": "11-Jun-2022", "python_version": null, "post_history": "`27-Jun-2022 <https://discuss.python.org/t/pep-694-upload-2-0-api-for-python-package-repositories/16879>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0694/", "abstract": "\nAbstract\nThere is currently no standardized API for uploading files to a Python package\nrepository such as PyPI. Instead, everyone has been forced to reverse engineer\nthe non-standard API from PyPI.\nThat API, while functional, leaks a lot of implementation details of the original\nPyPI code base, which have now had to have been faithfully replicated in the new\ncode base, and alternative implementations.\nBeyond the above, there are a number of major issues with the current API:\n\nIt is a fully synchronous API, which means that we're forced to have a single\nrequest being held open for potentially a long time, both for the upload itself,\nand then while the repository processes the uploaded file to determine success\nor failure.\nIt does not support any mechanism for resuming an upload, with the largest file\nsize on PyPI being just under 1GB in size, that's a lot of wasted bandwidth if\na large file has a network blip towards the end of an upload.\nIt treats a single file as the atomic unit of operation, which can be problematic\nwhen a release might have multiple binary wheels which can cause people to get\ndifferent versions while the files are uploading, and if the sdist happens to\nnot go last, possibly some hard to build packages are attempting to be built\nfrom source.\nIt has very limited support for communicating back to the user, with no support\nfor multiple errors, warnings, deprecations, etc. It is limited entirely to the\nHTTP status code and reason phrase, of which the reason phrase has been\ndeprecated since HTTP/2 (RFC 7540).\nThe metadata for a release/file is submitted alongside the file, however this\nmetadata is famously unreliable, and most installers instead choose to download\nthe entire file and read that in part due to that unreliability.\nThere is no mechanism for allowing a repository to do any sort of sanity\nchecks before bandwidth starts getting expended on an upload, whereas a lot\nof the cases of invalid metadata or incorrect permissions could be checked\nprior to upload.\nIt has no support for \"staging\" a draft release prior to publishing it to the\nrepository.\nIt has no support for creating new projects, without uploading a file.\n\nThis PEP proposes a new API for uploads, and deprecates the existing non standard\nAPI.\n"}, | |
| {"id": "695", "title": "Type Parameter Syntax", "authors": "Traut", "discussions_to": "https://mail.python.org/archives/list/typing-sig@python.org/thread/BB2BGYJY2YG5IWESKGTAPUQL3N27ZKVW/", "status": "Draft", "type": "Standards Track", "topic": "typing", "created": "15-Jun-2022", "python_version": "3.12", "post_history": "`20-Jun-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/BB2BGYJY2YG5IWESKGTAPUQL3N27ZKVW/>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0695/", "abstract": "\nAbstract\nThis PEP specifies an improved syntax for specifying type parameters within\na generic class, function, or type alias. It also introduces a new statement\nfor declaring type aliases.\n"}, | |
| {"id": "696", "title": "Type defaults for TypeVarLikes", "authors": "Hilton-Balfe", "discussions_to": "typing-sig@python.org", "status": "Draft", "type": "Standards Track", "topic": "typing", "created": "14-Jul-2022", "python_version": "3.12", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0696/", "abstract": "\nAbstract\nThis PEP introduces the concept of type defaults for\nTypeVarLikes (TypeVar, ParamSpec and TypeVarTuple),\nwhich act as defaults for a type parameter when one is not specified or\nthe constraint solver isn't able to solve a type parameter to anything.\nDefault type argument support is available in some popular languages\nsuch as C++, TypeScript, and Rust. A survey of type parameter syntax in\nsome common languages has been conducted by the author of PEP 695\nand can be found in its\nAppendix A.\n"}, | |
| {"id": "697", "title": "Limited C API for Extending Opaque Types", "authors": "Viktorin", "discussions_to": "https://discuss.python.org/t/19743", "status": "Draft", "type": "Standards Track", "topic": "", "created": "23-Aug-2022", "python_version": "3.12", "post_history": "`24-May-2022 <https://mail.python.org/archives/list/capi-sig@python.org/thread/SIP3VP7JU4OBWP62KBOYGOYCVIOTXEFH/>`__, `06-Oct-2022 <https://discuss.python.org/t/19743>`__,", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0697/", "abstract": "\nAbstract\nAdd Limited C API\nfor extending types with opaque data,\nby allowing code to only deal with data specific to a particular (sub)class.\nMake the mechanism usable with PyHeapTypeObject.\n"}, | |
| {"id": "698", "title": "Override Decorator for Static Typing", "authors": "Troxler, Xu, Zhu", "discussions_to": "https://mail.python.org/archives/list/typing-sig@python.org/thread/TOIYZ3SNPBJZDBRU3ZSBREXV2NNHF4KW/", "status": "Draft", "type": "Standards Track", "topic": "typing", "created": "05-Sep-2022", "python_version": "3.12", "post_history": "`20-May-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/V23I4D6DEOFW4BBPWBMYTHZUOMKR7KQE/>`__, `17-Aug-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/7JDW2PKGF6YTERUJGWM3BRP3GDHRFP4O/>`__, `11-Oct-2022 <https://mail.python.org/archives/list/typing-sig@python.org/thread/TOIYZ3SNPBJZDBRU3ZSBREXV2NNHF4KW/>`__,", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0698/", "abstract": "\nAbstract\nThis PEP proposes adding an @override decorator to the Python type system.\nThis will allow type checkers to prevent a class of bugs that occur when a base\nclass changes methods that are inherited by derived classes.\n"}, | |
| {"id": "699", "title": "Remove private dict version field added in PEP 509", "authors": "Jin", "discussions_to": "https://discuss.python.org/t/pep-699-remove-private-dict-version-field-added-in-pep-509/19724", "status": "Draft", "type": "Standards Track", "topic": "", "created": "03-Oct-2022", "python_version": "3.12", "post_history": "`05-Oct-2022 <https://discuss.python.org/t/pep-699-remove-private-dict-version-field-added-in-pep-509/19724>`__", "resolution": "", "requires": null, "replaces": "509", "superseded_by": null, "url": "https://peps.python.org/pep-0699/", "abstract": "\nAbstract\nPEP 509 introduced a private ma_version_tag field for dictionaries to\nallow optimizations in CPython and extension libraries. This PEP proposes to\nrescind PEP 509 and declare the field an implementation detail, as it has\nalready been superseded by alternatives. This will further allow the field to\nbe reused for future optimization.\n"}, | |
| {"id": "700", "title": "Additional Fields for the Simple API for Package Indexes", "authors": "Moore", "discussions_to": "https://discuss.python.org/t/pep-700-additional-fields-for-the-simple-api-for-package-indexes/20177", "status": "Draft", "type": "Standards Track", "topic": "packaging", "created": "21-Oct-2022", "python_version": null, "post_history": "`21-Oct-2022 <https://discuss.python.org/t/pep-700-additional-fields-for-the-simple-api-for-package-indexes/20177>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0700/", "abstract": "\nAbstract\nPEP 691 defined a JSON form for the \"Simple Repository API\". This allowed\nclients to more easily query the data that was previously only available in\nHTML, as defined in PEP 503.\nThis proposal adds three fields to the JSON form, which allow it to be used in\nplace of PyPI's JSON API\nin a number of situations.\n\nA field to allow retrieval of a list of all the published versions of a project.\nFields containing the size and upload time for a project file.\n\n"}, | |
| {"id": "754", "title": "IEEE 754 Floating Point Special Values", "authors": "Warnes", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "28-Mar-2003", "python_version": "2.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0754/", "abstract": "\nAbstract\nThis PEP proposes an API and a provides a reference module that\ngenerates and tests for IEEE 754 double-precision special values:\npositive infinity, negative infinity, and not-a-number (NaN).\n"}, | |
| {"id": "801", "title": "Reserved", "authors": "Warsaw", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "21-Jun-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0801/", "abstract": "\nAbstract\nThis PEP is reserved for future use, because\nWe are the 801.\nContact the author for details.\n"}, | |
| {"id": "3000", "title": "Python 3000", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "05-Apr-2006", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3000/", "abstract": "\nAbstract\nThis PEP sets guidelines for Python 3000 development. Ideally, we\nfirst agree on the process, and start discussing features only after\nthe process has been decided and specified. In practice, we'll be\ndiscussing features and process simultaneously; often the debate about\na particular feature will prompt a process discussion.\n"}, | |
| {"id": "3001", "title": "Procedure for reviewing and improving standard library modules", "authors": "Brandl", "discussions_to": null, "status": "Withdrawn", "type": "Process", "topic": "", "created": "05-Apr-2006", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3001/", "abstract": "\nAbstract\nThis PEP describes a procedure for reviewing and improving standard\nlibrary modules, especially those written in Python, making them ready\nfor Python 3000. There can be different steps of refurbishing, each\nof which is described in a section below. Of course, not every step\nhas to be performed for every module.\n"}, | |
| {"id": "3002", "title": "Procedure for Backwards-Incompatible Changes", "authors": "Bethard", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "27-Mar-2006", "python_version": null, "post_history": "27-Mar-2006, 13-Apr-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3002/", "abstract": "\nAbstract\nThis PEP describes the procedure for changes to Python that are\nbackwards-incompatible between the Python 2.X series and Python 3000.\nAll such changes must be documented by an appropriate Python 3000 PEP\nand must be accompanied by code that can identify when pieces of\nPython 2.X code may be problematic in Python 3000.\n"}, | |
| {"id": "3003", "title": "Python Language Moratorium", "authors": "Cannon, Noller, GvR", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "21-Oct-2009", "python_version": null, "post_history": "03-Nov-2009", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3003/", "abstract": "\nAbstract\nThis PEP proposes a temporary moratorium (suspension) of all changes\nto the Python language syntax, semantics, and built-ins for a period\nof at least two years from the release of Python 3.1. In particular, the\nmoratorium would include Python 3.2 (to be released 18-24 months after\n3.1) but allow Python 3.3 (assuming it is not released prematurely) to\nonce again include language changes.\nThis suspension of features is designed to allow non-CPython implementations\nto \"catch up\" to the core implementation of the language, help ease adoption\nof Python 3.x, and provide a more stable base for the community.\n"}, | |
| {"id": "3099", "title": "Things that will Not Change in Python 3000", "authors": "Brandl", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "04-Apr-2006", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3099/", "abstract": "\nAbstract\nSome ideas are just bad. While some thoughts on Python evolution are\nconstructive, some go against the basic tenets of Python so\negregiously that it would be like asking someone to run in a circle:\nit gets you nowhere, even for Python 3000, where extraordinary\nproposals are allowed. This PEP tries to list all BDFL pronouncements\non Python 3000 that refer to changes that will not happen and new\nfeatures that will not be introduced, sorted by topics, along with\na short explanation or a reference to the relevant thread on the\npython-3000 mailing list.\nIf you think you should suggest any of the listed ideas it would be\nbetter to just step away from the computer, go outside, and enjoy\nyourself. Being active outdoors by napping in a nice patch of grass\nis more productive than bringing up a beating-a-dead-horse idea and\nhaving people tell you how dead the idea is. Consider yourself warned.\n"}, | |
| {"id": "3100", "title": "Miscellaneous Python 3.0 Plans", "authors": "Cannon", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "20-Aug-2004", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3100/", "abstract": "\nAbstract\nThis PEP, previously known as PEP 3000, describes smaller scale changes\nand new features for which no separate PEP is written yet, all targeted\nfor Python 3000.\nThe list of features included in this document is subject to change\nand isn't binding on the Python development community; features may be\nadded, removed, and modified at any time. The purpose of this list is\nto focus our language development effort on changes that are steps to\n3.0, and to encourage people to invent ways to smooth the transition.\nThis document is not a wish-list that anyone can extend. While there\nare two authors of this PEP, we're just supplying the text; the\ndecisions for which changes are listed in this document are made by\nGuido van Rossum, who has chosen them as goals for Python 3.0.\nGuido's pronouncements on things that will not change in Python 3.0\nare recorded in PEP 3099.\n"}, | |
| {"id": "3101", "title": "Advanced String Formatting", "authors": "Talin", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-Apr-2006", "python_version": "3.0", "post_history": "28-Apr-2006, 06-May-2006, 10-Jun-2007, 14-Aug-2007, 14-Sep-2008", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3101/", "abstract": "\nAbstract\nThis PEP proposes a new system for built-in string formatting\noperations, intended as a replacement for the existing '%' string\nformatting operator.\n"}, | |
| {"id": "3102", "title": "Keyword-Only Arguments", "authors": "Talin", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "22-Apr-2006", "python_version": "3.0", "post_history": "28-Apr-2006, 19-May-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3102/", "abstract": "\nAbstract\nThis PEP proposes a change to the way that function arguments are\nassigned to named parameter slots. In particular, it enables the\ndeclaration of \"keyword-only\" arguments: arguments that can only\nbe supplied by keyword and which will never be automatically\nfilled in by a positional argument.\n"}, | |
| {"id": "3103", "title": "A Switch/Case Statement", "authors": "GvR", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "25-Jun-2006", "python_version": "3.0", "post_history": "26-Jun-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3103/", "abstract": "\nAbstract\nPython-dev has recently seen a flurry of discussion on adding a switch\nstatement. In this PEP I'm trying to extract my own preferences from\nthe smorgasbord of proposals, discussing alternatives and explaining\nmy choices where I can. I'll also indicate how strongly I feel about\nalternatives I discuss.\nThis PEP should be seen as an alternative to PEP 275. My views are\nsomewhat different from that PEP's author, but I'm grateful for the\nwork done in that PEP.\nThis PEP introduces canonical names for the many variants that have\nbeen discussed for different aspects of the syntax and semantics, such\nas \"alternative 1\", \"school II\", \"option 3\" and so on. Hopefully\nthese names will help the discussion.\n"}, | |
| {"id": "3104", "title": "Access to Names in Outer Scopes", "authors": "Yee", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "12-Oct-2006", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3104/", "abstract": "\nAbstract\nIn most languages that support nested scopes, code can refer to or\nrebind (assign to) any name in the nearest enclosing scope.\nCurrently, Python code can refer to a name in any enclosing scope,\nbut it can only rebind names in two scopes: the local scope (by\nsimple assignment) or the module-global scope (using a global\ndeclaration).\nThis limitation has been raised many times on the Python-Dev mailing\nlist and elsewhere, and has led to extended discussion and many\nproposals for ways to remove this limitation. This PEP summarizes\nthe various alternatives that have been suggested, together with\nadvantages and disadvantages that have been mentioned for each.\n"}, | |
| {"id": "3105", "title": "Make print a function", "authors": "Brandl", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Nov-2006", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3105/", "abstract": "\nAbstract\nThe title says it all - this PEP proposes a new print() builtin\nthat replaces the print statement and suggests a specific signature\nfor the new function.\n"}, | |
| {"id": "3106", "title": "Revamping dict.keys(), .values() and .items()", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Dec-2006", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3106/", "abstract": "\nIntroduction\nIt has long been the plan to change the .keys(), .values() and\n.items() methods of the built-in dict type to return a more\nlightweight object than a list, and to get rid of .iterkeys(),\n.itervalues() and .iteritems(). The idea is that code that currently\n(in 2.x) reads:\nfor k, v in d.iteritems(): ...\n\n\nshould be rewritten as:\nfor k, v in d.items(): ...\n\n\n(and similar for .itervalues() and .iterkeys(), except the latter is\nredundant since we can write that loop as for k in d.)\nCode that currently reads:\na = d.keys() # assume we really want a list here\n\n\n(etc.) should be rewritten as\n\na = list(d.keys())\nThere are (at least) two ways to accomplish this. The original plan\nwas to simply let .keys(), .values() and .items() return an iterator,\ni.e. exactly what iterkeys(), itervalues() and iteritems() return in\nPython 2.x. However, the Java Collections Framework [1] suggests\nthat a better solution is possible: the methods return objects with\nset behavior (for .keys() and .items()) or multiset (== bag) behavior\n(for .values()) that do not contain copies of the keys, values or\nitems, but rather reference the underlying dict and pull their values\nout of the dict as needed.\nThe advantage of this approach is that one can still write code like\nthis:\na = d.items()\nfor k, v in a: ...\n# And later, again:\nfor k, v in a: ...\n\n\nEffectively, iter(d.keys()) (etc.) in Python 3.0 will do what\nd.iterkeys() (etc.) does in Python 2.x; but in most contexts we don't\nhave to write the iter() call because it is implied by a for-loop.\nThe objects returned by the .keys() and .items() methods behave like\nsets. The object returned by the values() method behaves like a much\nsimpler unordered collection - it cannot be a set because duplicate\nvalues are possible.\nBecause of the set behavior, it will be possible to check whether two\ndicts have the same keys by simply testing:\nif a.keys() == b.keys(): ...\n\n\nand similarly for .items().\nThese operations are thread-safe only to the extent that using them in\na thread-unsafe way may cause an exception but will not cause\ncorruption of the internal representation.\nAs in Python 2.x, mutating a dict while iterating over it using an\niterator has an undefined effect and will in most cases raise a\nRuntimeError exception. (This is similar to the guarantees made by\nthe Java Collections Framework.)\nThe objects returned by .keys() and .items() are fully interoperable\nwith instances of the built-in set and frozenset types; for example:\nset(d.keys()) == d.keys()\n\n\nis guaranteed to be True (except when d is being modified\nsimultaneously by another thread).\n"}, | |
| {"id": "3107", "title": "Function Annotations", "authors": "Winter, Lownds", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "02-Dec-2006", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3107/", "abstract": "\nAbstract\nThis PEP introduces a syntax for adding arbitrary metadata annotations\nto Python functions [1].\n"}, | |
| {"id": "3108", "title": "Standard Library Reorganization", "authors": "Cannon", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-Jan-2007", "python_version": "3.0", "post_history": "28-Apr-2008", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3108/", "abstract": "\nAbstract\nJust like the language itself, Python's standard library (stdlib) has\ngrown over the years to be very rich. But over time some modules\nhave lost their need to be included with Python. There has also been\nan introduction of a naming convention for modules since Python's\ninception that not all modules follow.\nPython 3.0 presents a chance to remove modules that do not have\nlong term usefulness. This chance also allows for the renaming of\nmodules so that they follow the Python style guide. This\nPEP lists modules that should not be included in Python 3.0 or which\nneed to be renamed.\n"}, | |
| {"id": "3109", "title": "Raising Exceptions in Python 3000", "authors": "Winter", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "19-Jan-2006", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3109/", "abstract": "\nAbstract\nThis PEP introduces changes to Python's mechanisms for raising\nexceptions intended to reduce both line noise and the size of the\nlanguage.\n"}, | |
| {"id": "3110", "title": "Catching Exceptions in Python 3000", "authors": "Winter", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-Jan-2006", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3110/", "abstract": "\nAbstract\nThis PEP introduces changes intended to help eliminate ambiguities\nin Python's grammar, simplify exception classes, simplify garbage\ncollection for exceptions and reduce the size of the language in\nPython 3.0.\n"}, | |
| {"id": "3111", "title": "Simple input built-in in Python 3000", "authors": "Roberge", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "13-Sep-2006", "python_version": "3.0", "post_history": "22-Dec-2006", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3111/", "abstract": "\nAbstract\nInput and output are core features of computer programs. Currently,\nPython provides a simple means of output through the print keyword\nand two simple means of interactive input through the input()\nand raw_input() built-in functions.\nPython 3.0 will introduce various incompatible changes with previous\nPython versions (PEP 3100).\nAmong the proposed changes, print will become a built-in\nfunction, print(), while input() and raw_input() would be removed completely\nfrom the built-in namespace, requiring importing some module to provide\neven the most basic input capability.\nThis PEP proposes that Python 3.0 retains some simple interactive user\ninput capability, equivalent to raw_input(), within the built-in namespace.\nIt was accepted by the BDFL in December 2006 [5].\n"}, | |
| {"id": "3112", "title": "Bytes literals in Python 3000", "authors": "Orendorff", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "23-Feb-2007", "python_version": "3.0", "post_history": "23-Feb-2007", "resolution": null, "requires": "358", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3112/", "abstract": "\nAbstract\nThis PEP proposes a literal syntax for the bytes objects\nintroduced in PEP 358. The purpose is to provide a convenient way to\nspell ASCII strings and arbitrary binary data.\n"}, | |
| {"id": "3113", "title": "Removal of Tuple Parameter Unpacking", "authors": "Cannon", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "02-Mar-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3113/", "abstract": "\nAbstract\nTuple parameter unpacking is the use of a tuple as a parameter in a\nfunction signature so as to have a sequence argument automatically\nunpacked. An example is:\ndef fxn(a, (b, c), d):\n pass\n\n\nThe use of (b, c) in the signature requires that the second\nargument to the function be a sequence of length two (e.g.,\n[42, -13]). When such a sequence is passed it is unpacked and\nhas its values assigned to the parameters, just as if the statement\nb, c = [42, -13] had been executed in the parameter.\nUnfortunately this feature of Python's rich function signature\nabilities, while handy in some situations, causes more issues than\nthey are worth. Thus this PEP proposes their removal from the\nlanguage in Python 3.0.\n"}, | |
| {"id": "3114", "title": "Renaming iterator.next() to iterator.__next__()", "authors": "Yee", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "04-Mar-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3114/", "abstract": "\nAbstract\nThe iterator protocol in Python 2.x consists of two methods:\n__iter__() called on an iterable object to yield an iterator, and\nnext() called on an iterator object to yield the next item in the\nsequence. Using a for loop to iterate over an iterable object\nimplicitly calls both of these methods. This PEP proposes that the\nnext method be renamed to __next__, consistent with all the\nother protocols in Python in which a method is implicitly called as\npart of a language-level protocol, and that a built-in function named\nnext be introduced to invoke __next__ method, consistent with\nthe manner in which other protocols are explicitly invoked.\n"}, | |
| {"id": "3115", "title": "Metaclasses in Python 3000", "authors": "Talin", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "07-Mar-2007", "python_version": "3.0", "post_history": "11-Mar-2007, 14-Mar-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3115/", "abstract": "\nAbstract\nThis PEP proposes changing the syntax for declaring metaclasses,\nand alters the semantics for how classes with metaclasses are\nconstructed.\n"}, | |
| {"id": "3116", "title": "New I/O", "authors": "Stutzbach, GvR, Verdone", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Feb-2007", "python_version": "3.0", "post_history": "26-Feb-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3116/", "abstract": ""}, | |
| {"id": "3117", "title": "Postfix type declarations", "authors": "Brandl", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "01-Apr-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3117/", "abstract": "\nAbstract\nThis PEP proposes the addition of a postfix type declaration syntax to\nPython. It also specifies a new typedef statement which is used to create\nnew mappings between types and declarators.\nIts acceptance will greatly enhance the Python user experience as well as\neliminate one of the warts that deter users of other programming languages from\nswitching to Python.\n"}, | |
| {"id": "3118", "title": "Revising the buffer protocol", "authors": "Oliphant, Banks", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Aug-2006", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3118/", "abstract": "\nAbstract\nThis PEP proposes re-designing the buffer interface (PyBufferProcs\nfunction pointers) to improve the way Python allows memory sharing in\nPython 3.0\nIn particular, it is proposed that the character buffer portion\nof the API be eliminated and the multiple-segment portion be\nre-designed in conjunction with allowing for strided memory\nto be shared. In addition, the new buffer interface will\nallow the sharing of any multi-dimensional nature of the\nmemory and what data-format the memory contains.\nThis interface will allow any extension module to either\ncreate objects that share memory or create algorithms that\nuse and manipulate raw memory from arbitrary objects that\nexport the interface.\n"}, | |
| {"id": "3119", "title": "Introducing Abstract Base Classes", "authors": "GvR, Talin", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "18-Apr-2007", "python_version": "3.0", "post_history": "26-Apr-2007, 11-May-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3119/", "abstract": "\nAbstract\nThis is a proposal to add Abstract Base Class (ABC) support to Python\n3000. It proposes:\n\nA way to overload isinstance() and issubclass().\nA new module abc which serves as an \"ABC support framework\". It\ndefines a metaclass for use with ABCs and a decorator that can be\nused to define abstract methods.\nSpecific ABCs for containers and iterators, to be added to the\ncollections module.\n\nMuch of the thinking that went into the proposal is not about the\nspecific mechanism of ABCs, as contrasted with Interfaces or Generic\nFunctions (GFs), but about clarifying philosophical issues like \"what\nmakes a set\", \"what makes a mapping\" and \"what makes a sequence\".\nThere's also a companion PEP 3141, which defines ABCs for numeric\ntypes.\n\nAcknowledgements\nTalin wrote the Rationale below [1] as well as most of the section on\nABCs vs. Interfaces. For that alone he deserves co-authorship. The\nrest of the PEP uses \"I\" referring to the first author.\n\n"}, | |
| {"id": "3120", "title": "Using UTF-8 as the default source encoding", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "15-Apr-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3120/", "abstract": ""}, | |
| {"id": "3121", "title": "Extension Module Initialization and Finalization", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Accepted", "type": "Standards Track", "topic": "", "created": "27-Apr-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3121/", "abstract": "\nAbstract\nExtension module initialization currently has a few deficiencies.\nThere is no cleanup for modules, the entry point name might give\nnaming conflicts, the entry functions don't follow the usual calling\nconvention, and multiple interpreters are not supported well. This PEP\naddresses these issues.\n"}, | |
| {"id": "3122", "title": "Delineation of the main module", "authors": "Cannon", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "27-Apr-2007", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3122/", "abstract": "\nAbstract\nBecause of how name resolution works for relative imports in a world\nwhere PEP 328 is implemented, the ability to execute modules within a\npackage ceases being possible. This failing stems from the fact that\nthe module being executed as the \"main\" module replaces its\n__name__ attribute with \"__main__\" instead of leaving it as\nthe absolute name of the module. This breaks import's ability\nto resolve relative imports from the main module into absolute names.\nIn order to resolve this issue, this PEP proposes to change how the\nmain module is delineated. By leaving the __name__ attribute in\na module alone and setting sys.main to the name of the main\nmodule this will allow at least some instances of executing a module\nwithin a package that uses relative imports.\nThis PEP does not address the idea of introducing a module-level\nfunction that is automatically executed like PEP 299 proposes.\n"}, | |
| {"id": "3123", "title": "Making PyObject_HEAD conform to standard C", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "27-Apr-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3123/", "abstract": "\nAbstract\nPython currently relies on undefined C behavior, with its\nusage of PyObject_HEAD. This PEP proposes to change that\ninto standard C.\n"}, | |
| {"id": "3124", "title": "Overloading, Generic Functions, Interfaces, and Adaptation", "authors": "Eby", "discussions_to": "python-3000@python.org", "status": "Deferred", "type": "Standards Track", "topic": "", "created": "28-Apr-2007", "python_version": null, "post_history": "30-Apr-2007", "resolution": null, "requires": "3107, 3115, 3119", "replaces": "245, 246", "superseded_by": null, "url": "https://peps.python.org/pep-3124/", "abstract": "\nAbstract\nThis PEP proposes a new standard library module, overloading, to\nprovide generic programming features including dynamic overloading\n(aka generic functions), interfaces, adaptation, method combining (ala\nCLOS and AspectJ), and simple forms of aspect-oriented programming\n(AOP).\nThe proposed API is also open to extension; that is, it will be\npossible for library developers to implement their own specialized\ninterface types, generic function dispatchers, method combination\nalgorithms, etc., and those extensions will be treated as first-class\ncitizens by the proposed API.\nThe API will be implemented in pure Python with no C, but may have\nsome dependency on CPython-specific features such as sys._getframe\nand the func_code attribute of functions. It is expected that\ne.g. Jython and IronPython will have other ways of implementing\nsimilar functionality (perhaps using Java or C#).\n"}, | |
| {"id": "3125", "title": "Remove Backslash Continuation", "authors": "Jewett", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "29-Apr-2007", "python_version": null, "post_history": "29-Apr-2007, 30-Apr-2007, 04-May-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3125/", "abstract": "\nAbstract\nPython initially inherited its parsing from C. While this has been\ngenerally useful, there are some remnants which have been less useful\nfor Python, and should be eliminated.\nThis PEP proposes elimination of terminal \\ as a marker for line\ncontinuation.\n"}, | |
| {"id": "3126", "title": "Remove Implicit String Concatenation", "authors": "Jewett, Hettinger", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "29-Apr-2007", "python_version": null, "post_history": "29-Apr-2007, 30-Apr-2007, 07-May-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3126/", "abstract": "\nAbstract\nPython inherited many of its parsing rules from C. While this has\nbeen generally useful, there are some individual rules which are less\nuseful for python, and should be eliminated.\nThis PEP proposes to eliminate implicit string concatenation based\nonly on the adjacency of literals.\nInstead of:\n\"abc\" \"def\" == \"abcdef\"\n\n\nauthors will need to be explicit, and either add the strings:\n\"abc\" + \"def\" == \"abcdef\"\n\n\nor join them:\n\"\".join([\"abc\", \"def\"]) == \"abcdef\"\n\n\n"}, | |
| {"id": "3127", "title": "Integer Literal Support and Syntax", "authors": "Maupin", "discussions_to": "python-3000@python.org", "status": "Final", "type": "Standards Track", "topic": "", "created": "14-Mar-2007", "python_version": "3.0", "post_history": "18-Mar-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3127/", "abstract": "\nAbstract\nThis PEP proposes changes to the Python core to rationalize\nthe treatment of string literal representations of integers\nin different radices (bases). These changes are targeted at\nPython 3.0, but the backward-compatible parts of the changes\nshould be added to Python 2.6, so that all valid 3.0 integer\nliterals will also be valid in 2.6.\nThe proposal is that:\n\noctal literals must now be specified\nwith a leading \"0o\" or \"0O\" instead of \"0\";\nbinary literals are now supported via a\nleading \"0b\" or \"0B\"; and\nprovision will be made for binary numbers in\nstring formatting.\n\n"}, | |
| {"id": "3128", "title": "BList: A Faster List-like Type", "authors": "Stutzbach", "discussions_to": "python-3000@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "30-Apr-2007", "python_version": "2.6, 3.0", "post_history": "30-Apr-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3128/", "abstract": "\nAbstract\nThe common case for list operations is on small lists. The current\narray-based list implementation excels at small lists due to the\nstrong locality of reference and infrequency of memory allocation\noperations. However, an array takes O(n) time to insert and delete\nelements, which can become problematic as the list gets large.\nThis PEP introduces a new data type, the BList, that has array-like\nand tree-like aspects. It enjoys the same good performance on small\nlists as the existing array-based implementation, but offers superior\nasymptotic performance for most operations. This PEP proposes\nreplacing the makes two mutually exclusive proposals for including the\nBList type in Python:\n\nAdd it to the collections module, or\nReplace the existing list type\n\n"}, | |
| {"id": "3129", "title": "Class Decorators", "authors": "Winter", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-May-2007", "python_version": "3.0", "post_history": "07-May-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3129/", "abstract": "\nAbstract\nThis PEP proposes class decorators, an extension to the function\nand method decorators introduced in PEP 318.\n"}, | |
| {"id": "3130", "title": "Access to Current Module/Class/Function", "authors": "Jewett", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "22-Apr-2007", "python_version": "3.0", "post_history": "22-Apr-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3130/", "abstract": "\nAbstract\nIt is common to need a reference to the current module, class,\nor function, but there is currently no entirely correct way to\ndo this. This PEP proposes adding the keywords __module__,\n__class__, and __function__.\n"}, | |
| {"id": "3131", "title": "Supporting Non-ASCII Identifiers", "authors": "von L\u00f6wis", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "01-May-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3131/", "abstract": "\nAbstract\nThis PEP suggests to support non-ASCII letters (such as accented characters,\nCyrillic, Greek, Kanji, etc.) in Python identifiers.\n"}, | |
| {"id": "3132", "title": "Extended Iterable Unpacking", "authors": "Brandl", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "30-Apr-2007", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3132/", "abstract": "\nAbstract\nThis PEP proposes a change to iterable unpacking syntax, allowing to\nspecify a \"catch-all\" name which will be assigned a list of all items\nnot assigned to a \"regular\" name.\nAn example says more than a thousand words:\n>>> a, *b, c = range(5)\n>>> a\n0\n>>> c\n4\n>>> b\n[1, 2, 3]\n\n\n"}, | |
| {"id": "3133", "title": "Introducing Roles", "authors": "Winter", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "01-May-2007", "python_version": "3.0", "post_history": "13-May-2007", "resolution": null, "requires": "3115, 3129", "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3133/", "abstract": "\nAbstract\nPython's existing object model organizes objects according to their\nimplementation. It is often desirable - especially in\nduck typing-based language like Python - to organize objects by\nthe part they play in a larger system (their intent), rather than by\nhow they fulfill that part (their implementation). This PEP\nintroduces the concept of roles, a mechanism for organizing\nobjects according to their intent rather than their implementation.\n"}, | |
| {"id": "3134", "title": "Exception Chaining and Embedded Tracebacks", "authors": "Yee", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "12-May-2005", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3134/", "abstract": "\nAbstract\nThis PEP proposes three standard attributes on exception instances: the\n__context__ attribute for implicitly chained exceptions, the __cause__\nattribute for explicitly chained exceptions, and the __traceback__\nattribute for the traceback. A new raise ... from statement sets the\n__cause__ attribute.\n"}, | |
| {"id": "3135", "title": "New Super", "authors": "Spealman, Delaney, Ryan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "28-Apr-2007", "python_version": "3.0", "post_history": "`28-Apr-2007 <https://mail.python.org/pipermail/python-dev/2007-April/072807.html>`__, `29-Apr-2007 <https://mail.python.org/pipermail/python-dev/2007-April/072835.html>`__, `29-Apr-2007 <https://mail.python.org/pipermail/python-dev/2007-April/072858.html>`__, `14-May-2007 <https://mail.python.org/pipermail/python-dev/2007-May/073127.html>`__, `12-Mar-2009 <https://mail.python.org/pipermail/python-bugs-list/2009-March/072665.html>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3135/", "abstract": "\nAbstract\nThis PEP proposes syntactic sugar for use of the super type to automatically\nconstruct instances of the super type binding to the class that a method was\ndefined in, and the instance (or class object for classmethods) that the method\nis currently acting upon.\nThe premise of the new super usage suggested is as follows:\nsuper().foo(1, 2)\n\n\nto replace the old:\nsuper(Foo, self).foo(1, 2)\n\n\n"}, | |
| {"id": "3136", "title": "Labeled break and continue", "authors": "Chisholm", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "30-Jun-2007", "python_version": "3.1", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3136/", "abstract": "\nIntroduction\nThe break statement allows the programmer to terminate a loop\nearly, and the continue statement allows the programmer to move to\nthe next iteration of a loop early. In Python currently, break\nand continue can apply only to the innermost enclosing loop.\nAdding support for labels to the break and continue statements\nis a logical extension to the existing behavior of the break and\ncontinue statements. Labeled break and continue can\nimprove the readability and flexibility of complex code which uses\nnested loops.\nFor brevity's sake, the examples and discussion in this PEP usually\nrefers to the break statement. However, all of the examples and\nmotivations apply equally to labeled continue.\n"}, | |
| {"id": "3137", "title": "Immutable Bytes and Mutable Buffer", "authors": "GvR", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "26-Sep-2007", "python_version": "3.0", "post_history": "26-Sep-2007, 30-Sep-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3137/", "abstract": "\nIntroduction\nAfter releasing Python 3.0a1 with a mutable bytes type, pressure\nmounted to add a way to represent immutable bytes. Gregory P. Smith\nproposed a patch that would allow making a bytes object temporarily\nimmutable by requesting that the data be locked using the new buffer\nAPI from PEP 3118. This did not seem the right approach to me.\nJeffrey Yasskin, with the help of Adam Hupp, then prepared a patch to\nmake the bytes type immutable (by crudely removing all mutating APIs)\nand fix the fall-out in the test suite. This showed that there aren't\nall that many places that depend on the mutability of bytes, with the\nexception of code that builds up a return value from small pieces.\nThinking through the consequences, and noticing that using the array\nmodule as an ersatz mutable bytes type is far from ideal, and\nrecalling a proposal put forward earlier by Talin, I floated the\nsuggestion to have both a mutable and an immutable bytes type. (This\nhad been brought up before, but until seeing the evidence of Jeffrey's\npatch I wasn't open to the suggestion.)\nMoreover, a possible implementation strategy became clear: use the old\nPyString implementation, stripped down to remove locale support and\nimplicit conversions to/from Unicode, for the immutable bytes type,\nand keep the new PyBytes implementation as the mutable bytes type.\nThe ensuing discussion made it clear that the idea is welcome but\nneeds to be specified more precisely. Hence this PEP.\n"}, | |
| {"id": "3138", "title": "String representation in Python 3000", "authors": "Ishimoto", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "05-May-2008", "python_version": "3.0", "post_history": "05-May-2008, 05-Jun-2008", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3138/", "abstract": "\nAbstract\nThis PEP proposes a new string representation form for Python 3000.\nIn Python prior to Python 3000, the repr() built-in function converted\narbitrary objects to printable ASCII strings for debugging and\nlogging. For Python 3000, a wider range of characters, based on the\nUnicode standard, should be considered 'printable'.\n"}, | |
| {"id": "3139", "title": "Cleaning out sys and the \"interpreter\" module", "authors": "Peterson", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "04-Apr-2008", "python_version": "3.0", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3139/", "abstract": "\nAbstract\nThis PEP proposes a new low-level module for CPython-specific interpreter\nfunctions in order to clean out the sys module and separate general Python\nfunctionality from implementation details.\n"}, | |
| {"id": "3140", "title": "str(container) should call str(item), not repr(item)", "authors": "Broytman, Jewett", "discussions_to": "python-3000@python.org", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "27-May-2008", "python_version": null, "post_history": "28-May-2008", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3140/", "abstract": "\nAbstract\nThis document discusses the advantages and disadvantages of the\ncurrent implementation of str(container). It also discusses the\npros and cons of a different approach - to call str(item) instead\nof repr(item).\n"}, | |
| {"id": "3141", "title": "A Type Hierarchy for Numbers", "authors": "Yasskin", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "23-Apr-2007", "python_version": "3.0", "post_history": "25-Apr-2007, 16-May-2007, 02-Aug-2007", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3141/", "abstract": "\nAbstract\nThis proposal defines a hierarchy of Abstract Base Classes (ABCs) (PEP\n3119) to represent number-like classes. It proposes a hierarchy of\nNumber :> Complex :> Real :> Rational :> Integral where A :> B\nmeans \"A is a supertype of B\". The hierarchy is inspired by Scheme's\nnumeric tower [3].\n"}, | |
| {"id": "3142", "title": "Add a \"while\" clause to generator expressions", "authors": "Britton", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "12-Jan-2009", "python_version": "3.0", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2013-May/126136.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3142/", "abstract": "\nAbstract\nThis PEP proposes an enhancement to generator expressions, adding a\n\"while\" clause to complement the existing \"if\" clause.\n"}, | |
| {"id": "3143", "title": "Standard daemon process library", "authors": "Finney", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "26-Jan-2009", "python_version": "3.x", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3143/", "abstract": "\nAbstract\nWriting a program to become a well-behaved Unix daemon is somewhat\ncomplex and tricky to get right, yet the steps are largely similar for\nany daemon regardless of what else the program may need to do.\nThis PEP introduces a package to the Python standard library that\nprovides a simple interface to the task of becoming a daemon process.\n"}, | |
| {"id": "3144", "title": "IP Address Manipulation Library for the Python Standard Library", "authors": "Moody", "discussions_to": "ipaddr-py-dev@googlegroups.com", "status": "Final", "type": "Standards Track", "topic": "", "created": "06-Feb-2012", "python_version": "3.3", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2012-May/119474.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3144/", "abstract": "\nAbstract\nThis PEP proposes a design and for an IP address manipulation module for\npython.\n"}, | |
| {"id": "3145", "title": "Asynchronous I/O For subprocess.Popen", "authors": "Pruitt, McCreary, Carlson", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "04-Aug-2009", "python_version": "3.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3145/", "abstract": "\nAbstract\nIn its present form, the subprocess.Popen implementation is prone to\ndead-locking and blocking of the parent Python script while waiting on data\nfrom the child process. This PEP proposes to make\nsubprocess.Popen more asynchronous to help alleviate these\nproblems.\n"}, | |
| {"id": "3146", "title": "Merging Unladen Swallow into CPython", "authors": "Winter, Yasskin, Kleckner", "discussions_to": null, "status": "Withdrawn", "type": "Standards Track", "topic": "", "created": "01-Jan-2010", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3146/", "abstract": "\nAbstract\nThis PEP proposes the merger of the Unladen Swallow project [3] into\nCPython's source tree. Unladen Swallow is an open-source branch of CPython\nfocused on performance. Unladen Swallow is source-compatible with valid Python\n2.6.4 applications and C extension modules.\nUnladen Swallow adds a just-in-time (JIT) compiler to CPython, allowing for the\ncompilation of selected Python code to optimized machine code. Beyond classical\nstatic compiler optimizations, Unladen Swallow's JIT compiler takes advantage of\ndata collected at runtime to make checked assumptions about code behaviour,\nallowing the production of faster machine code.\nThis PEP proposes to integrate Unladen Swallow into CPython's development tree\nin a separate py3k-jit branch, targeted for eventual merger with the main\npy3k branch. While Unladen Swallow is by no means finished or perfect, we\nfeel that Unladen Swallow has reached sufficient maturity to warrant\nincorporation into CPython's roadmap. We have sought to create a stable platform\nthat the wider CPython development team can build upon, a platform that will\nyield increasing performance for years to come.\nThis PEP will detail Unladen Swallow's implementation and how it differs from\nCPython 2.6.4; the benchmarks used to measure performance; the tools used to\nensure correctness and compatibility; the impact on CPython's current platform\nsupport; and the impact on the CPython core development process. The PEP\nconcludes with a proposed merger plan and brief notes on possible directions\nfor future work.\nWe seek the following from the BDFL:\n\nApproval for the overall concept of adding a just-in-time compiler to CPython,\nfollowing the design laid out below.\nPermission to continue working on the just-in-time compiler in the CPython\nsource tree.\nPermission to eventually merge the just-in-time compiler into the py3k\nbranch once all blocking issues [31] have been addressed.\nA pony.\n\n"}, | |
| {"id": "3147", "title": "PYC Repository Directories", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-Dec-2009", "python_version": "3.2", "post_history": "30-Jan-2010, 25-Feb-2010, 03-Mar-2010, 12-Apr-2010", "resolution": "https://mail.python.org/pipermail/python-dev/2010-April/099414.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3147/", "abstract": "\nAbstract\nThis PEP describes an extension to Python's import mechanism which\nimproves sharing of Python source code files among multiple installed\ndifferent versions of the Python interpreter. It does this by\nallowing more than one byte compilation file (.pyc files) to be\nco-located with the Python source file (.py file). The extension\ndescribed here can also be used to support different Python\ncompilation caches, such as JIT output that may be produced by an\nUnladen Swallow (PEP 3146) enabled C Python.\n"}, | |
| {"id": "3148", "title": "futures - execute computations asynchronously", "authors": "Quinlan", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "16-Oct-2009", "python_version": "3.2", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3148/", "abstract": "\nAbstract\nThis PEP proposes a design for a package that facilitates the\nevaluation of callables using threads and processes.\n"}, | |
| {"id": "3149", "title": "ABI version tagged .so files", "authors": "Warsaw", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "09-Jul-2010", "python_version": "3.2", "post_history": "14-Jul-2010, 22-Jul-2010", "resolution": "https://mail.python.org/pipermail/python-dev/2010-September/103408.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3149/", "abstract": "\nAbstract\nPEP 3147 described an extension to Python's import machinery that\nimproved the sharing of Python source code, by allowing more than one\nbyte compilation file (.pyc) to be co-located with each source file.\nThis PEP defines an adjunct feature which allows the co-location of\nextension module files (.so) in a similar manner. This optional,\nbuild-time feature will enable downstream distributions of Python to\nmore easily provide more than one Python major version at a time.\n"}, | |
| {"id": "3150", "title": "Statement local namespaces (aka \"given\" clause)", "authors": "Coghlan", "discussions_to": null, "status": "Deferred", "type": "Standards Track", "topic": "", "created": "09-Jul-2010", "python_version": "3.4", "post_history": "14-Jul-2010, 21-Apr-2011, 13-Jun-2011", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3150/", "abstract": "\nAbstract\nThis PEP proposes the addition of an optional given clause to several\nPython statements that do not currently have an associated code suite. This\nclause will create a statement local namespace for additional names that are\naccessible in the associated statement, but do not become part of the\ncontaining namespace.\nAdoption of a new symbol, ?, is proposed to denote a forward reference\nto the namespace created by running the associated code suite. It will be\na reference to a types.SimpleNamespace object.\nThe primary motivation is to enable a more declarative style of programming,\nwhere the operation to be performed is presented to the reader first, and the\ndetails of the necessary subcalculations are presented in the following\nindented suite. As a key example, this would elevate ordinary assignment\nstatements to be on par with class and def statements where the name\nof the item to be defined is presented to the reader in advance of the\ndetails of how the value of that item is calculated. It also allows named\nfunctions to be used in a \"multi-line lambda\" fashion, where the name is used\nsolely as a placeholder in the current expression and then defined in the\nfollowing suite.\nA secondary motivation is to simplify interim calculations in module and\nclass level code without polluting the resulting namespaces.\nThe intent is that the relationship between a given clause and a separate\nfunction definition that performs the specified operation will be similar to\nthe existing relationship between an explicit while loop and a generator that\nproduces the same sequence of operations as that while loop.\nThe specific proposal in this PEP has been informed by various explorations\nof this and related concepts over the years (e.g. [1], [2], [3], [6],\n[8]), and is inspired to some degree by the where and let clauses in\nHaskell. It avoids some problems that have been identified in past proposals,\nbut has not yet itself been subject to the test of implementation.\n"}, | |
| {"id": "3151", "title": "Reworking the OS and IO exception hierarchy", "authors": "Pitrou", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "21-Jul-2010", "python_version": "3.3", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2011-October/114033.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3151/", "abstract": "\nAbstract\nThe standard exception hierarchy is an important part of the Python\nlanguage. It has two defining qualities: it is both generic and\nselective. Generic in that the same exception type can be raised\n- and handled - regardless of the context (for example, whether you are\ntrying to add something to an integer, to call a string method, or to write\nan object on a socket, a TypeError will be raised for bad argument types).\nSelective in that it allows the user to easily handle (silence, examine,\nprocess, store or encapsulate...) specific kinds of error conditions\nwhile letting other errors bubble up to higher calling contexts. For\nexample, you can choose to catch ZeroDivisionErrors without affecting\nthe default handling of other ArithmeticErrors (such as OverflowErrors).\nThis PEP proposes changes to a part of the exception hierarchy in\norder to better embody the qualities mentioned above: the errors\nrelated to operating system calls (OSError, IOError, mmap.error,\nselect.error, and all their subclasses).\n"}, | |
| {"id": "3152", "title": "Cofunctions", "authors": "Ewing", "discussions_to": null, "status": "Rejected", "type": "Standards Track", "topic": "", "created": "13-Feb-2009", "python_version": "3.3", "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3152/", "abstract": "\nAbstract\nA syntax is proposed for defining and calling a special type of\ngenerator called a 'cofunction'. It is designed to provide a\nstreamlined way of writing generator-based coroutines, and allow the\nearly detection of certain kinds of error that are easily made when\nwriting such code, which otherwise tend to cause hard-to-diagnose\nsymptoms.\nThis proposal builds on the 'yield from' mechanism described in PEP\n380, and describes some of the semantics of cofunctions in terms of\nit. However, it would be possible to define and implement cofunctions\nindependently of PEP 380 if so desired.\n\nRejection\nSee https://mail.python.org/pipermail/python-dev/2015-April/139503.html\n\n"}, | |
| {"id": "3153", "title": "Asynchronous IO support", "authors": "Houtven", "discussions_to": null, "status": "Superseded", "type": "Standards Track", "topic": "", "created": "29-May-2011", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": "3156", "url": "https://peps.python.org/pep-3153/", "abstract": "\nAbstract\nThis PEP describes an abstraction of asynchronous IO for the Python\nstandard library.\nThe goal is to reach an abstraction that can be implemented by many\ndifferent asynchronous IO backends and provides a target for library\ndevelopers to write code portable between those different backends.\n"}, | |
| {"id": "3154", "title": "Pickle protocol version 4", "authors": "Pitrou", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "11-Aug-2011", "python_version": "3.4", "post_history": "`12-Aug-2011 <https://mail.python.org/pipermail/python-dev/2011-August/112821.html>`__", "resolution": "https://mail.python.org/pipermail/python-dev/2013-November/130439.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3154/", "abstract": "\nAbstract\nData serialized using the pickle module must be portable across Python\nversions. It should also support the latest language features as well\nas implementation-specific features. For this reason, the pickle\nmodule knows about several protocols (currently numbered from 0 to 3),\neach of which appeared in a different Python version. Using a\nlow-numbered protocol version allows to exchange data with old Python\nversions, while using a high-numbered protocol allows access to newer\nfeatures and sometimes more efficient resource use (both CPU time\nrequired for (de)serializing, and disk size / network bandwidth\nrequired for data transfer).\n"}, | |
| {"id": "3155", "title": "Qualified name for classes and functions", "authors": "Pitrou", "discussions_to": null, "status": "Final", "type": "Standards Track", "topic": "", "created": "29-Oct-2011", "python_version": "3.3", "post_history": null, "resolution": "https://mail.python.org/pipermail/python-dev/2011-November/114545.html", "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-3155/", "abstract": ""}, | |
| {"id": "3156", "title": "Asynchronous IO Support Rebooted: the \"asyncio\" Module", "authors": "GvR", "discussions_to": "python-tulip@googlegroups.com", "status": "Final", "type": "Standards Track", "topic": "", "created": "12-Dec-2012", "python_version": "3.3", "post_history": "21-Dec-2012", "resolution": "https://mail.python.org/pipermail/python-dev/2013-November/130419.html", "requires": null, "replaces": "3153", "superseded_by": null, "url": "https://peps.python.org/pep-3156/", "abstract": "\nIntroduction\n\nStatus\nA reference implementation exists under the code name Tulip. The\nTulip repo is linked from the References section at the end. Packages\nbased on this repo will be provided on PyPI (see References) to enable\nusing the asyncio package with Python 3.3 installations.\nAs of October 20th 2013, the asyncio package has been checked into\nthe Python 3.4 repository and released with Python 3.4-alpha-4, with\n\"provisional\" API status. This is an expression of confidence and\nintended to increase early feedback on the API, and not intended to\nforce acceptance of the PEP. The expectation is that the package will\nkeep provisional status in Python 3.4 and progress to final status in\nPython 3.5. Development continues to occur primarily in the Tulip\nrepo, with changes occasionally merged into the CPython repo.\n\n\nDependencies\nPython 3.3 is required for many of the proposed features. The\nreference implementation (Tulip) requires no new language or standard\nlibrary features beyond Python 3.3, no third-party modules or\npackages, and no C code, except for the (optional) IOCP support on\nWindows.\n\n\nModule Namespace\nThe specification here lives in a new top-level package, asyncio.\nDifferent components live in separate submodules of the package. The\npackage will import common APIs from their respective submodules and\nmake them available as package attributes (similar to the way the\nemail package works). For such common APIs, the name of the submodule\nthat actually defines them is not part of the specification. Less\ncommon APIs may have to explicitly be imported from their respective\nsubmodule, and in this case the submodule name is part of the\nspecification.\nClasses and functions defined without a submodule name are assumed to\nlive in the namespace of the top-level package. (But do not confuse\nthese with methods of various classes, which for brevity are also used\nwithout a namespace prefix in certain contexts.)\n\n\nInteroperability\nThe event loop is the place where most interoperability occurs. It\nshould be easy for (Python 3.3 ports of) frameworks like Twisted,\nTornado, or even gevents to either adapt the default event loop\nimplementation to their needs using a lightweight adapter or proxy, or\nto replace the default event loop implementation with an adaptation of\ntheir own event loop implementation. (Some frameworks, like Twisted,\nhave multiple event loop implementations. This should not be a\nproblem since these all have the same interface.)\nIn most cases it should be possible for two different third-party\nframeworks to interoperate, either by sharing the default event loop\nimplementation (each using its own adapter), or by sharing the event\nloop implementation of either framework. In the latter case two\nlevels of adaptation would occur (from framework A's event loop to the\nstandard event loop interface, and from there to framework B's event\nloop). Which event loop implementation is used should be under\ncontrol of the main program (though a default policy for event loop\nselection is provided).\nFor this interoperability to be effective, the preferred direction of\nadaptation in third party frameworks is to keep the default event loop\nand adapt it to the framework's API. Ideally all third party\nframeworks would give up their own event loop implementation in favor\nof the standard implementation. But not all frameworks may be\nsatisfied with the functionality provided by the standard\nimplementation.\nIn order to support both directions of adaptation, two separate APIs\nare specified:\n\nAn interface for managing the current event loop\nThe interface of a conforming event loop\n\nAn event loop implementation may provide additional methods and\nguarantees, as long as these are called out in the documentation as\nnon-standard. An event loop implementation may also leave certain\nmethods unimplemented if they cannot be implemented in the given\nenvironment; however, such deviations from the standard API should be\nconsidered only as a last resort, and only if the platform or\nenvironment forces the issue. (An example would be a platform where\nthere is a system event loop that cannot be started or stopped; see\n\"Embedded Event Loops\" below.)\nThe event loop API does not depend on await/yield from. Rather, it uses\na combination of callbacks, additional interfaces (transports and\nprotocols), and Futures. The latter are similar to those defined in\nPEP 3148, but have a different implementation and are not tied to\nthreads. In particular, the result() method raises an exception\ninstead of blocking when a result is not yet ready; the user is\nexpected to use callbacks (or await/yield from) to wait for the result.\nAll event loop methods specified as returning a coroutine are allowed\nto return either a Future or a coroutine, at the implementation's\nchoice (the standard implementation always returns coroutines). All\nevent loop methods documented as accepting coroutine arguments must\naccept both Futures and coroutines for such arguments. (A convenience\nfunction, ensure_future(), exists to convert an argument that is either a\ncoroutine or a Future into a Future.)\nFor users (like myself) who don't like using callbacks, a scheduler is\nprovided for writing asynchronous I/O code as coroutines using the PEP\n380 yield from or PEP 492 await expressions.\nThe scheduler is not pluggable;\npluggability occurs at the event loop level, and the standard\nscheduler implementation should work with any conforming event loop\nimplementation. (In fact this is an important litmus test for\nconforming implementations.)\nFor interoperability between code written using coroutines and other\nasync frameworks, the scheduler defines a Task class that behaves like a\nFuture. A framework that interoperates at the event loop level can\nwait for a Future to complete by adding a callback to the Future.\nLikewise, the scheduler offers an operation to suspend a coroutine\nuntil a callback is called.\nIf such a framework cannot use the Future and Task classes as-is, it\nmay reimplement the loop.create_future() and\nloop.create_task() methods. These should return objects\nimplementing (a superset of) the Future/Task interfaces.\nA less ambitious framework may just call the\nloop.set_task_factory() to replace the Task class without\nimplementing its own event loop.\nThe event loop API provides limited interoperability with threads:\nthere is an API to submit a function to an executor (see PEP 3148)\nwhich returns a Future that is compatible with the event loop, and\nthere is a method to schedule a callback with an event loop from\nanother thread in a thread-safe manner.\n\n\nTransports and Protocols\nFor those not familiar with Twisted, a quick explanation of the\nrelationship between transports and protocols is in order. At the\nhighest level, the transport is concerned with how bytes are\ntransmitted, while the protocol determines which bytes to transmit\n(and to some extent when).\nA different way of saying the same thing: a transport is an\nabstraction for a socket (or similar I/O endpoint) while a protocol is\nan abstraction for an application, from the transport's point of view.\nYet another view is simply that the transport and protocol interfaces\ntogether define an abstract interface for using network I/O and\ninterprocess I/O.\nThere is almost always a 1:1 relationship between transport and\nprotocol objects: the protocol calls transport methods to send data,\nwhile the transport calls protocol methods to pass it data that has\nbeen received. Neither transport nor protocol methods \"block\" - they\nset events into motion and then return.\nThe most common type of transport is a bidirectional stream transport.\nIt represents a pair of buffered streams (one in each direction) that\neach transmit a sequence of bytes. The most common example of a\nbidirectional stream transport is probably a TCP connection. Another\ncommon example is an SSL/TLS connection. But there are some other things\nthat can be viewed this way, for example an SSH session or a pair of\nUNIX pipes. Typically there aren't many different transport\nimplementations, and most of them come with the event loop\nimplementation. However, there is no requirement that all transports\nmust be created by calling an event loop method: a third party module\nmay well implement a new transport and provide a constructor or\nfactory function for it that simply takes an event loop as an argument\nor calls get_event_loop().\nNote that transports don't need to use sockets, not even if they use\nTCP - sockets are a platform-specific implementation detail.\nA bidirectional stream transport has two \"ends\": one end talks to\nthe network (or another process, or whatever low-level interface it\nwraps), and the other end talks to the protocol. The former uses\nwhatever API is necessary to implement the transport; but the\ninterface between transport and protocol is standardized by this PEP.\nA protocol can represent some kind of \"application-level\" protocol\nsuch as HTTP or SMTP; it can also implement an abstraction shared by\nmultiple protocols, or a whole application. A protocol's primary\ninterface is with the transport. While some popular protocols (and\nother abstractions) may have standard implementations, often\napplications implement custom protocols. It also makes sense to have\nlibraries of useful third party protocol implementations that can be\ndownloaded and installed from PyPI.\nThere general notion of transport and protocol includes other\ninterfaces, where the transport wraps some other communication\nabstraction. Examples include interfaces for sending and receiving\ndatagrams (e.g. UDP), or a subprocess manager. The separation of\nconcerns is the same as for bidirectional stream transports and\nprotocols, but the specific interface between transport and protocol\nis different in each case.\nDetails of the interfaces defined by the various standard types of\ntransports and protocols are given later.\n\n"}, | |
| {"id": "3333", "title": "Python Web Server Gateway Interface v1.0.1", "authors": "Eby", "discussions_to": "web-sig@python.org", "status": "Final", "type": "Informational", "topic": "", "created": "26-Sep-2010", "python_version": null, "post_history": "26-Sep-2010, 04-Oct-2010", "resolution": null, "requires": null, "replaces": "333", "superseded_by": null, "url": "https://peps.python.org/pep-3333/", "abstract": "\nAbstract\nThis document specifies a proposed standard interface between web\nservers and Python web applications or frameworks, to promote web\napplication portability across a variety of web servers.\n"}, | |
| {"id": "8000", "title": "Python Language Governance Proposal Overview", "authors": "Warsaw", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "24-Aug-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8000/", "abstract": "\nAbstract\nThis PEP provides an overview of the selection process for a new model of\nPython language governance in the wake of Guido's retirement.\nOnce the governance model is selected, it will be codified in PEP 13.\nHere is a list of PEPs related to the governance model selection process.\nPEPs in the lower 8000s describe the general process for selecting a\ngovernance model.\n\nPEP 8001 - Python Governance Voting ProcessThis PEP describes how the vote for the new governance model will be\nconducted. It outlines the voting method, timeline, criteria for\nparticipation, and explicit list of eligible voters.\n\nPEP 8002 - Open Source Governance SurveySurveys will be conducted of governance models for similar open source and\nfree software projects, and summaries of these models will be outlined in\nthis PEP. These surveys will serve as useful barometers for how such\nprojects can be successfully governed, and may serve as inspiration for\nPython's own governance model. Python is unique, so it's expected that it\nwill have its own spin on governance, rather than directly adopting any of\nthose surveyed.\n\n\nPEPs in the 801Xs describe the actual proposals for Python governance. It is\nexpected that these PEPs will cover the broad scope of governance, and that\ndifferences in details (such as the size of a governing council) will be\ncovered in the same PEP, rather than in potentially vote-splitting individual\nPEPs.\n\nPEP 8010 - The Technical Leader Governance ModelThis PEP proposes a continuation of the singular technical project\nleader model. Also within scope is whether an advisory council aids\nor supports the BDFL. This PEP does not name either the next\nBDFL, nor members of such an advisory council. For that, see PEP\n13.\n\nPEP 8011 - Python Governance Model Lead by Trio of PythonistasThis PEP describes a new model of Python governance lead by a Trio of Pythonistas\n(TOP). It describes the role and responsibilities of the Trio.\nThis PEP does not name members of the Trio. For that, see PEP 13.\n\nPEP 8012 - The Community Governance ModelThis is a placeholder PEP for a new model of Python governance based on\nconsensus and voting, without the role of a centralized singular leader or a\ngoverning council. It describes how, when, and why votes are conducted for\ndecisions affecting the Python language. It also describes the criteria for\nvoting eligibility.\n\nPEP 8013 - The External Governance ModelThis PEP describes a new model of Python governance based on an external\ncouncil who are responsible for ensuring good process. Elected by the core\ndevelopment team, this council may reject proposals that are not\nsufficiently detailed, do not consider all affected users, or are not\nappropriate for the upcoming release. This PEP does not name members of\nsuch a council. For that, see PEP 13.\n\nPEP 8014 - The Commons Governance ModelThis PEP describes a new model of Python governance based on a council of\nelders who are responsible for ensuring a PEP is supported by a sufficient\nmajority of the Python community before being accepted. Unlike some of the\nother governance PEPs it explicitly does not specify who has voting\nrights and what a majority vote consists of. In stead this is determined\nby the council of elders on a case-by-case basis.\n\nPEP 8015 - Organization of the Python communityThis PEP formalizes the current organization of the Python community\nand proposes 3 main changes: formalize the existing concept of\n\"Python teams\"; give more autonomy to Python teams; replace the BDFL\n(Guido van Rossum) with a new \"Python board\" of 3 members which has\nlimited roles, mostly decide how a PEP is approved (or rejected).\n\nPEP 8016 - The Steering Council ModelThis PEP proposes a model of Python governance based around a\nsteering council. The council has broad authority, which they seek\nto exercise as rarely as possible; instead, they use this power to\nestablish standard processes, like those proposed in the other\n801x-series PEPs. This follows the general philosophy that it's\nbetter to split up large changes into a series of small changes that\ncan be reviewed independently: instead of trying to do everything in\none PEP, we focus on providing a minimal-but-solid foundation for\nfurther governance decisions.\n\n\nAdditional governance models may be added before the final selection.\n"}, | |
| {"id": "8001", "title": "Python Governance Voting Process", "authors": "Cannon, Heimes, Stufft, Snow, Smith, Langa, Mariatta, Smith, Salgado, Hettinger, Einat, Peters, Ware", "discussions_to": null, "status": "Final", "type": "Process", "topic": "", "created": "24-Aug-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8001/", "abstract": "\nAbstract\nThis PEP outlines the process for how the new model of Python governance is\nselected, in the wake of Guido's retirement.\nOnce the model is chosen by the procedures outlined here, it will be codified\nin PEP 13.\n"}, | |
| {"id": "8002", "title": "Open Source Governance Survey", "authors": "Warsaw, Langa, Pitrou, Hellmann, Willing", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "24-Aug-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8002/", "abstract": "\nAbstract\nThis PEP surveys existing and similar open source and free software projects\nfor their governance models, providing summaries that will serve as useful\nreferences for Python's own selection of a new governance model in the wake of\nGuido's retirement.\nRather than an individual PEP for each of these community surveys, they will\nall be collected here in this PEP.\n"}, | |
| {"id": "8010", "title": "The Technical Leader Governance Model", "authors": "Warsaw", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "24-Aug-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8010/", "abstract": "\nAbstract\nThis PEP proposes a continuation of the singular technical project\nleader model, euphemistically called the Benevolent Dictator For Life (BDFL)\nmodel of Python governance, to be henceforth called in this PEP the\nGracious Umpire Influencing Decisions Officer (GUIDO). This change in\nname reflects both the expanded view of the GUIDO as final arbiter for\nthe Python language decision making process in consultation with the\nwider development community, and the recognition that \"for life\" while\nperhaps aspirational, is not necessarily in the best interest of the\nwell-being of either the language or the GUIDO themselves.\nThis PEP describes:\n\nThe rationale for maintaining the singular technical leader model\nThe process for how the GUIDO will be selected, elected, retained,\nrecalled, and succeeded;\nThe roles of the GUIDO in the Python language evolution process;\nThe term length of service;\nThe relationship of the GUIDO with a Council of Pythonistas (CoP)\nthat advise the GUIDO on technical matters;\nThe size, election, and roles of the CoP;\nThe decision delegation process;\nAny changes to the PEP process to fit the new governance model;\n\nThis PEP does not name a new BDFL. Should this model be adopted, it\nwill be codified in PEP 13 along with the names of all officeholders\ndescribed in this PEP.\n"}, | |
| {"id": "8011", "title": "Python Governance Model Lead by Trio of Pythonistas", "authors": "Mariatta, Warsaw", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "24-Aug-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8011/", "abstract": "\nAbstract\nThis PEP proposes a governance model for the Core Python development community,\nled by a trio of equally authoritative leaders. The Trio of Pythonistas\n(ToP, or simply Trio) is tasked with making final decisions for the language.\nIt differs from PEP 8010 by specifically not proposing a central singular leader,\nbut instead a group of three people as the leaders.\nThis PEP also proposes a formation of specialized workgroups to assist the leadership\ntrio in making decisions.\nThis PEP does not name the members of the Trio. Should this model be adopted,\nit will be codified in PEP 13 along with the names of all officeholders\ndescribed in this PEP.\nThis PEP describes:\n\nThe role and responsibilities of the Trio\nGuidelines of how trio members should be formed\nReasoning of the group of three, instead of a singular leader\nRole and responsibilities of Python core developers to the trio\nSustainability considerations\nDiversity and inclusivity considerations\n\n"}, | |
| {"id": "8012", "title": "The Community Governance Model", "authors": "Langa", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "03-Oct-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8012/", "abstract": "\nAbstract\nThis PEP proposes a new model of Python governance based on consensus\nand voting by the Python community. This model relies on workgroups to carry\nout the governance of the Python language. This governance model works without\nthe role of a centralized singular leader or a governing council.\nIt describes how, when, and why votes are conducted for decisions affecting\nthe Python language. It also describes the criteria for voting eligibility.\nShould this model be adopted, it will be codified in PEP 13.\nThis model can be affectionately called \"The Least Worst Governance\nModel\" by its property that while far from ideal, it's still the most\nrobust one compared to the others. Since avoiding issues inherent to\nthe other models is a paramount feature of the Community Governance\nModel, we start the discussion a bit unusually: by rejecting the\nother models.\n"}, | |
| {"id": "8013", "title": "The External Council Governance Model", "authors": "Dower", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "14-Sep-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8013/", "abstract": "\nAbstract\nThis PEP proposes a new model of Python governance based on a Council\nof Auditors (CoA) tasked with making final decisions for the language.\nIt differs from PEP 8010 by specifically not proposing a central\nsingular leader, and from PEP 8011 by disallowing core committers from\nbeing council members. It describes the size and role of the council,\nhow the initial group of council members will be chosen, any term\nlimits of the council members, and how successors will be elected.\nIt also spends significant time discussing the intended behaviour of\nthis model. By design, many processes are not specified here but are\nleft to the people involved. In order to select people who will make\nthe best decisions, it is important for those involved to understand\nthe expectations of the CoA but it is equally important to allow the\nCoA the freedom to adjust process requirements for varying\ncircumstances. This only works when process is unspecified, but all\nparticipants have similar expectations.\nThis PEP does not name the members of the CoA. Should this model be\nadopted, it will be codified in PEP 13 along with the names of all\nofficeholders described in this PEP.\n"}, | |
| {"id": "8014", "title": "The Commons Governance Model", "authors": "Jansen", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "16-Sep-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8014/", "abstract": "\nIntroduction\nThe Commons Governance Model tries to ensure that all decisions are endorsed\nby, or at least is acceptable to, a sufficient majority of the Python\ncommunity.\nUnfortunately the previous paragraph has two terms that are very hard to\nquantify in the general case: sufficient majority and Python community.\nThis is because both terms in reality depend on the specific case that is\nbeing decided. To give an example of this difficulty: for a PEP that\nproposes a backward-compatible change to some API a simple majority of the\ncore developers that were interested in voting on the PEP in the first place\nis probably sufficient. But for a change that has more farreaching\nconsequences such as a Python3 to Python4 transition a real majority may be\nwanted, and a demonstration that at least there seems to be sufficient\nsupport in the user base. And for a change that transcends the\nPython-the-language, such as decisions on abolishing non-inclusive language,\nit becomes very vague.\nThe Commons Governance Model attempts to sidestep this issue by not\ndefining what the terms sufficient majority and Python community mean in\nthe general case, by proposing a body that will decide so in specific\ncases.\nThe model proposes creating a Council of Elders that oversees the decision\nprocess, determining whether a specific proposal has enough support on a\ncase-by-case basis. There will be a vote on every individual PEP,\nand the Council of Elders will declare whether the\noutcome of the vote is sufficient to carry the decision in this specific case.\nThe model addresses only the roles traditionally held by the BDFL in the\ndecision process, not other roles.\nThe term Commons in the model name is loosely based on its historic use as\na shared resource to be used by all and cared for by all. The picture you\nshould have in mind with this model is a sizeable group of peasants\ndiscussing some plan for the future on the village green on a warm summer\nevening, after which the vote is taken and the village elders pronounce\nthe outcome. Then the banquet begins.\nThe Commons Governance Model is different from most of the other governance\nproposals (with the possible exception of 8012), because it explicitly places\nsupreme power with the whole community.\n"}, | |
| {"id": "8015", "title": "Organization of the Python community", "authors": "Stinner", "discussions_to": null, "status": "Rejected", "type": "Informational", "topic": "", "created": "04-Oct-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8015/", "abstract": "\nAbstract\nThis PEP formalizes the current organization of the Python community and\nproposes 3 main changes:\n\nFormalize the existing concept of \"Python teams\";\nGive more autonomy to Python teams;\nReplace the BDFL (Guido van Rossum) with a new \"Python Steering\nCommittee\" of 5 members which has limited roles: basically decide how\ndecisions are taken, but don't take decisions.\n\nPEPs are approved by a PEP delegate or by a vote (reserved to core\ndevelopers, need >= 2/3 majority).\n"}, | |
| {"id": "8016", "title": "The Steering Council Model", "authors": "Smith, Stufft", "discussions_to": null, "status": "Accepted", "type": "Informational", "topic": "", "created": "01-Nov-2018", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8016/", "abstract": "\nAbstract\nThis PEP proposes a model of Python governance based around a steering\ncouncil. The council has broad authority, which they seek to exercise\nas rarely as possible; instead, they use this power to establish\nstandard processes, like those proposed in the other 801x-series PEPs.\nThis follows the general philosophy that it's better to split up large\nchanges into a series of small changes that can be reviewed\nindependently: instead of trying to do everything in one PEP, we focus\non providing a minimal-but-solid foundation for further governance\ndecisions.\n"}, | |
| {"id": "8100", "title": "January 2019 steering council election", "authors": "Smith, Durbin", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "03-Jan-2019", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8100/", "abstract": "\nAbstract\nThis document describes the schedule and other details of the January\n2019 election for the Python steering council, as specified in\nPEP 13. This is the first steering council election.\n"}, | |
| {"id": "8101", "title": "2020 Term steering council election", "authors": "Jodlowska, Durbin", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "16-Nov-2019", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8101/", "abstract": "\nAbstract\nThis document describes the schedule and other details of the December\n2019 election for the Python steering council, as specified in\nPEP 13. This is steering council election for the 2020 term.\n"}, | |
| {"id": "8102", "title": "2021 Term steering council election", "authors": "Jodlowska, Durbin, Carey", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "29-Oct-2020", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8102/", "abstract": "\nAbstract\nThis document describes the schedule and other details of the December\n2020 election for the Python steering council, as specified in\nPEP 13. This is the steering council election for the 2021 term.\n"}, | |
| {"id": "8103", "title": "2022 Term steering council election", "authors": "Jodlowska, Durbin, Carey", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "04-Oct-2021", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-8103/", "abstract": "\nAbstract\nThis document describes the schedule and other details of the December\n2021 election for the Python steering council, as specified in\nPEP 13. This is the steering council election for the 2022 term\n(i.e. Python 3.11).\n"}, | |
| {"id": "0", "title": "Index of Python Enhancement Proposals (PEPs)", "authors": "python-dev", "discussions_to": null, "status": "Active", "type": "Informational", "topic": "", "created": "13-Jul-2000", "python_version": null, "post_history": null, "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "https://peps.python.org/pep-0000/", "abstract": "\nIntroduction\nThis PEP contains the index of all Python Enhancement Proposals,\nknown as PEPs. PEP numbers are assigned\nby the PEP editors, and once assigned are never changed. The\nversion control history of\nthe PEP texts represent their historical record. The PEPs are\nindexed by topic for specialist subjects.\n"} | |
| ] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import littletable as lt | |
| # import PEP data from JSON, converting created date stings to Python datetimes | |
| peps = lt.Table().json_import( | |
| "peps.json", | |
| transforms={"created": lt.Table.parse_date("%d-%b-%Y")} | |
| ) | |
| # print metadata of imported records | |
| print(peps.info()) | |
| # access records by unique PEP id | |
| peps.create_index("id", unique=True) | |
| print(peps.by.id["20"].title) | |
| # add a numeric "year" field | |
| peps.add_field("year", lambda pep: pep.created.year) | |
| peps.create_index("year") | |
| # present PEPs created in 2016 | |
| peps.by.year[2016].select("id title").present() | |
| # pivot by year and dump counts, or present as nice table | |
| peps.pivot("year").dump_counts() | |
| peps.pivot("year").as_table().present() | |
| # create full text search on PEP abstracts | |
| peps.create_search_index("abstract") | |
| walrus_pep = peps.search.abstract("walrus")[0][0] | |
| print(f"{walrus_pep.id} {walrus_pep.title} {walrus_pep.year} ") | |
| # search for PEPs referring to GvR or Guido or BDFL | |
| # (as_table requires littletable 2.1.1) | |
| if lt.__version_info__[:3] >= (2, 1, 1): | |
| bdfl_peps = peps.search.abstract("gvr guido bdfl", as_table=True) | |
| bdfl_peps.sort(lambda r: int(r.id)).select("id title year").present() |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment