SPEP Template

This SPEP template is a guideline of the sections that a SPEP should contain. Extra sections may be added if appropriate, and unnecessary sections may be noted as such.

Status

SPEPs go through a number of phases in their lifetime:

• Discussion: The SPEP is being actively discussed on the mailing list and it is being improved by its author. The mailing list discussion of the SPEP should include the SPEP number (SPEPxxx) in the subject line so they can be easily related to the SPEP.

• Progress: Consensus was reached and implementation work has begun.

• Completed: The implementation has been merged into main.

• Superseded: This SPEP has been abandoned in favor of another approach.

• Rejected: There are currently no plans to implement the proposal.

Branches and Pull requests

All development branches containing work on this SPEP should be linked to from here.

All pull requests submitted relating to this SPEP should be linked to from here. (A SPEP does not need to be implemented in a single pull request if it makes sense to implement it in discrete phases).

Abstract

The abstract should be a short description of what the SPEP will achieve.

Detailed description

This section describes the need for the SPEP. It should describe the existing problem that it is trying to solve and why this SPEP makes the situation better. It should include examples of how the new functionality would be used and perhaps some use cases.

Implementation

This section lists the major steps required to implement the SPEP. Where possible, it should be noted where one step is dependent on another, and which steps may be optionally omitted. Where it makes sense, each step should include a link related pull requests as the implementation progresses.

Backward compatibility

This section describes the ways in which the SPEP breaks backward incompatibility.

Alternatives

If there were any alternative solutions to solving the same problem, they should be discussed here, along with a justification for the chosen approach.