@@ -245,7 +245,22 @@ Once a PEP has been accepted, the reference implementation must be

completed. When the reference implementation is complete and incorporated

into the main source code repository, the status will be changed to "Final".

A PEP can also be assigned status "Deferred". The PEP author or an

To allow gathering of additional design and interface feedback before committing

to long term stability for a language feature or standard library API, a PEP

may also be marked as "Provisional". This is short for "Provisionally Accepted",

and indicates that the proposal has been accepted for inclusion in the reference

implementation, but additional user feedback is needed before the full design

can be considered "Final". Unlike regular accepted PEPs, provisionally accepted

PEPs may still be Rejected or Withdrawn *even after the related changes have

been included in a Python release*.

Wherever possible, it is considered preferable to reduce the scope of a proposal

to avoid the need to rely on the "Provisional" status (e.g. by deferring some

features to later PEPs), as this status can lead to version compatibility

challenges in the wider Python ecosystem. PEP 411 provides additional details

on potential use cases for the Provisional status.

A PEP can also be assigned the status "Deferred". The PEP author or an

editor can assign the PEP this status when no progress is being made

on the PEP. Once a PEP is deferred, a PEP editor can re-assign it

to draft status.

@@ -267,7 +282,16 @@ an API can replace version 1.

The possible paths of the status of PEPs are as follows:

.. image:: pep-0001-1.png

.. image:: pep-0001-1.svg

While not shown in the diagram, "Accepted" PEPs may technically move to

"Rejected" or "Withdrawn" even after acceptance. This will only occur if

the implementation process reveals fundamental flaws in the design that were

not noticed prior to acceptance of the PEP. Unlike Provisional PEPs, these

transitions are only permitted if the accepted proposal has *not* been included

in a Python release - released changes must instead go through the regular

deprecation process (which may require a new PEP providing the rationale for

the deprecation).

Some Informational and Process PEPs may also have a status of "Active"

if they are never meant to be completed. E.g. PEP 1 (this PEP).

@@ -281,6 +305,11 @@ reached the Final state. Once a PEP has been completed, the Language and

Standard Library References become the formal documentation of the expected

behavior.

If changes based on implementation experience and user feedback are made to

Standards track PEPs while in the Accepted or Provisional State, those changes

should be noted in the PEP, such that the PEP accurately describes the state of

the implementation at the point where it is marked Final.

Informational and Process PEPs may be updated over time to reflect changes

to development practices and other details. The precise process followed in

these cases will depend on the nature and purpose of the PEP being updated.

@@ -379,7 +408,7 @@ optional and are described below. All other headers are required. ::

Author: <list of authors' real names and optionally, email addrs>

* BDFL-Delegate: <PEP czar's real name>

* Discussions-To: <email address>

Status: <Draft | Active | Accepted | Deferred | Rejected |

Status: <Draft | Active | Accepted | Provisional | Deferred | Rejected |

Withdrawn | Final | Superseded>

Type: <Standards Track | Informational | Process>

* Content-Type: <text/x-rst | text/plain>