NXEP X — Template and Instructions

Author

<list of authors’ real names and optionally, email addresses>

Status

<Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded>

Type

<Standards Track | Process>

Created

<date created on, in yyyy-mm-dd format>

Resolution

<url> (required for Accepted | Rejected | Withdrawn)

Abstract

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

Note that the — in the title is an elongated dash, not -.

Motivation and Scope

This section describes the need for the proposed change. It should describe the existing problem, who it affects, what it is trying to solve, and why. This section should explicitly address the scope of and key requirements for the proposed change.

Usage and Impact

This section describes how users of NumPy will use features described in this NXEP. It should be comprised mainly of code examples that wouldn’t be possible without acceptance and implementation of this NXEP, as well as the impact the proposed changes would have on the ecosystem. This section should be written from the perspective of the users of NumPy, and the benefits it will provide them; and as such, it should include implementation details only if necessary to explain the functionality.

Backward compatibility

This section describes the ways in which the NXEP breaks backward compatibility.

The mailing list post will contain the NXEP up to and including this section. Its purpose is to provide a high-level summary to users who are not interested in detailed technical discussion, but may have opinions around, e.g., usage and impact.

Detailed description

This section should provide a detailed description of the proposed change. It should include examples of how the new functionality would be used, intended use-cases and pseudo-code illustrating its use.

Implementation

This section lists the major steps required to implement the NXEP. 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 to related pull requests as the implementation progresses.

Any pull requests or development branches containing work on this NXEP should be linked to from here. (A NXEP does not need to be implemented in a single pull request if it makes sense to implement it in discrete phases).

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.

Discussion

This section may just be a bullet list including links to any discussions regarding the NXEP:

  • This includes links to mailing list threads or relevant GitHub issues.