Status#

MEPs go through a number of phases in their lifetime:

• Discussion: The MEP is being actively discussed on the mailinglist and it is being improved by its author. The mailing listdiscussion of the MEP should include the MEP number (MEPxxx) in thesubject line so they can be easily related to the MEP.

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

• Completed: The implementation has been merged into main.

• Superseded: This MEP has been abandoned in favor of anotherapproach.

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

Branches and Pull requests#

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

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

Abstract#

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

Detailed description#

This section describes the need for the MEP. It should describe theexisting problem that it is trying to solve and why this MEP makes thesituation better. It should include examples of how the newfunctionality would be used and perhaps some use cases.

Implementation#

This section lists the major steps required to implement the MEP.Where possible, it should be noted where one step is dependent onanother, and which steps may be optionally omitted. Where it makessense, each step should include a link related pull requests as theimplementation progresses.

Backward compatibility#

This section describes the ways in which the MEP 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 thechosen approach.