Skip to content

Instantly share code, notes, and snippets.

Created Nov 9, 2022
What would you like to do?
{"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": "", "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": "", "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": "", "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\n\n\n\nGuidelines for people submitting Python bugs are at\n\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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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 <>`__, `14-May-2014 <>`__, `20-Feb-2015 <>`__, `10-Mar-2022 <>`__,", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "", "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 <>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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:\n\nOlder versions are available as:\n\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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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, 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": "", "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": "", "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": "", "status": "Superseded", "type": "Standards Track", "topic": "packaging", "created": "12-Mar-2001", "python_version": null, "post_history": "`19-Mar-2001 <>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": "314", "url": "", "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": "", "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": "", "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": "", "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 sdist),\nthey might type 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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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(\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": "", "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": "", "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": "", "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 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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "abstract": "\nAbstract\nThis PEP documents the semantics and conventions associated with\nPython docstrings.\n"},
{"id": "258", "title": "Docutils Design Specification", "authors": "Goodger", "discussions_to": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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 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": "", "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": "", "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 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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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 ->\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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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 (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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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\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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "status": "Superseded", "type": "Standards Track", "topic": "packaging", "created": "28-Apr-2005", "python_version": "2.7", "post_history": "`22-Dec-2009 <>`__", "resolution": "", "requires": null, "replaces": "314", "superseded_by": "566", "url": "", "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": "", "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": "", "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": "", "abstract": "\nAbstract\nThe Python source code is currently managed in a CVS repository on\ This PEP proposes to move it to a Subversion\nrepository on\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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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\n\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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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 <>`__, `29-Apr-2007 <>`__, `29-Apr-2007 <>`__, `14-May-2007 <>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "", "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:\, 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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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 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": "", "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": "", "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 <>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "10-Oct-2009", "python_version": "2.7, 3.2", "post_history": null, "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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\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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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 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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": "415", "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": "409", "superseded_by": null, "url": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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 <>`__", "resolution": null, "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "20-Sep-2012", "python_version": null, "post_history": "18-Oct-2012, 15-Feb-2013", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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 <>`__", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "abstract": "\nAbstract\nThis PEP proposes a strategy for migrating the default version of the\nPython documentation presented to users of Python when accessing\ 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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": "354", "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "status": "Superseded", "type": "Process", "topic": "packaging", "created": "15-Mar-2013", "python_version": null, "post_history": "19-May-2013", "resolution": "", "requires": null, "replaces": null, "superseded_by": "470", "url": "", "abstract": "\nAbstract\nThis PEP proposes a backward-compatible two-phase transition process\nto speed up, simplify and robustify installing from the\ (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": "", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "18-Mar-2013", "python_version": "3.4", "post_history": "19-Mar-2013", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "requires": null, "replaces": "386", "superseded_by": null, "url": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "status": "Final", "type": "Process", "topic": "packaging", "created": "04-Aug-2013", "python_version": null, "post_history": "04-Aug-2013", "resolution": "", "requires": null, "replaces": "381", "superseded_by": null, "url": "", "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 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": "", "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\n"},
{"id": "451", "title": "A ModuleSpec Type for the Import System", "authors": "Snow", "discussions_to": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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\n\nand for an earlier partial review, see\n .\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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "abstract": ""},
{"id": "458", "title": "Secure PyPI downloads with signed repository metadata", "authors": "Kuppusamy, Diaz, Moore, Puehringer, Lock, DeLong, Cappos", "discussions_to": "", "status": "Accepted", "type": "Standards Track", "topic": "packaging", "created": "27-Sep-2013", "python_version": null, "post_history": "06-Jan-2019, 13-Nov-2019", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "status": "Final", "type": "Process", "topic": "packaging", "created": "02-Mar-2014", "python_version": null, "post_history": "04-Mar-2014", "resolution": "", "requires": null, "replaces": "381", "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "status": "Final", "type": "Standards Track", "topic": "", "created": "05-Apr-2014", "python_version": "3.6", "post_history": "05-Apr-2014, 08-Sep-2016", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "requires": null, "replaces": "438", "superseded_by": null, "url": "", "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": "", "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": "", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "24-Jun-2014", "python_version": "3.6", "post_history": "02-Jul-2014", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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", "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": "", "abstract": "\nAbstract\nThis PEP proposes setting up a new PSF provided resource,,\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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": "422", "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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\ 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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "status": "Final", "type": "Standards Track", "topic": "", "created": "02-Aug-2015", "python_version": "3.6", "post_history": null, "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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 =, 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": "", "abstract": "\nAbstract\nWhen a module is used as a main program on the Python command line,\nsuch as by:\n\npython -m ...\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,\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": "", "status": "Rejected", "type": "Standards Track", "topic": "", "created": "08-Aug-2015", "python_version": null, "post_history": null, "resolution": "", "requires": "495", "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "04-Sep-2015", "python_version": null, "post_history": "04-Sep-2015", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "status": "Final", "type": "Standards Track", "topic": "packaging", "created": "11-Nov-2015", "python_version": null, "post_history": "05-Nov-2015, 16-Nov-2015", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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 to GitHub", "authors": "Cannon", "discussions_to": "", "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": "", "abstract": "\nAbstract\nThis PEP outlines the steps required to migrate Python's development\nprocess from Mercurial [3] as hosted at\ [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": "", "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": "", "requires": null, "replaces": null, "superseded_by": "600", "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "abstract": ""},
{"id": "516", "title": "Build system abstraction for pip/conda etc", "authors": "Collins, Smith", "discussions_to": "", "status": "Rejected", "type": "Standards Track", "topic": "packaging", "created": "26-Oct-2015", "python_version": null, "post_history": null, "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "requires": "506", "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "status": "Final", "type": "Process", "topic": "packaging", "created": "23-Aug-2016", "python_version": null, "post_history": "23-Aug-2016", "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "status": "Final", "type": "Process", "topic": "packaging", "created": "12-Jan-2017", "python_version": null, "post_history": null, "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "status": "Accepted", "type": "Standards Track", "topic": "typing", "created": "05-Mar-2017", "python_version": "3.8", "post_history": null, "resolution": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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 Examples of\ntwo active translation teams:\n\n French\n Japanese\n\n will redirect to\nSources of translated documentation will be hosted in the Python\norganization on GitHub: 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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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": "", "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": "", "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": "", "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": "", "requires": null, "replaces": null, "superseded_by": null, "url": "", "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 = name\n self.unit_price = unit_price\n self.quantity_on_hand = quantity_on_hand\ndef __repr__(self):\n return f'InventoryItem(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.unit_price, self.quantity_on_hand) == (, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __ne__(self, other):\n if other.__class__ is self.__class__:\n return (, self.unit_price, self.quantity_on_hand) != (, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __lt__(self, other):\n if other.__class__ is self.__class__:\n return (, self.unit_price, self.quantity_on_hand) < (, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __le__(self, other):\n if other.__class__ is self.__class__:\n return (, self.unit_price, self.quantity_on_hand) <= (, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __gt__(self, other):\n if other.__class__ is self.__class__:\n return (, self.unit_price, self.quantity_on_hand) > (, other.unit_price, other.quantity_on_hand)\n return NotImplemented\ndef __ge__(self, other):\n if other.__class__ is self.__class__:\n return (, self.unit_price, self.quantity_on_hand) >= (, 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": "", "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": "", "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"},