Ctrl+K

NEP X — 模板和说明#

作者：

<作者真实姓名列表以及可选的电子邮件地址>

地位：

<草稿|活跃|已接受 |延期|被拒绝 |撤回 |决赛|取代>

类型：

<标准轨道|流程>

创建：

<创建日期，格式为 yyyy-mm-dd>

解决：

<url>（接受|拒绝|撤回必需）

抽象的＃

摘要应该是对 NEP 将实现的目标的简短描述。

请注意，标题中的“-”是一个拉长的破折号，而不是“-”。

动机和范围#

本节描述了拟议变更的必要性。它应该描述现有的问题、它影响谁、它试图解决什么问题以及原因。本节应明确说明拟议变更的范围和关键要求。

使用和影响#

本节介绍 NumPy 用户将如何使用本 NEP 中描述的功能。它应该主要由代码示例组成，如果不接受和实施此 NEP，则不可能实现这些示例，以及拟议的更改将对生态系统产生的影响。本节应该从 NumPy 用户的角度编写，以及它将为他们提供的好处；因此，仅在需要解释功能时才应包含实现细节。

向后兼容性#

本节介绍 NEP 破坏向后兼容性的方式。

邮件列表帖子将包含 NEP，直至并包括本节。其目的是为对详细技术讨论不感兴趣但可能有意见（例如使用和影响）的用户提供高级摘要。

详细说明＃

本节应提供拟议变更的详细描述。它应该包括如何使用新功能的示例、预期用例和说明其使用的伪代码。

执行＃

本节列出了实施 NEP 所需的主要步骤。在可能的情况下，应注意其中一个步骤依赖于另一步骤，以及哪些步骤可以选择性地省略。在有意义的情况下，随着实施的进展，每个步骤都应该包含指向相关拉取请求的链接。

任何包含此 NEP 工作的拉取请求或开发分支都应从此处链接到。 （如果在离散阶段实现 NEP 有意义，则不需要在单个拉取请求中实现 NEP）。

备择方案＃

如果有任何替代解决方案可以解决同一问题，则应在此处进行讨论，并说明所选方法的理由。

讨论＃

本节可能只是一个项目符号列表，包括有关 NEP 的任何讨论的链接：

  • 这包括邮件列表主题或相关 GitHub 问题的链接。

参考文献和脚注#

在本页