NumPy路线图#

这是我们将投入资源的任务和功能的实时快照。它可用于鼓励和激励开发者并寻找资金。

互操作性#

我们的目标是简化与NumPy的互操作性。许多类似NumPy的软件包为Python生态系统增加了有趣的新功能，还有许多库以各种方式扩展了NumPy的模型。NumPy中促进与所有此类软件包及其使用代码的互操作性的工作可能包括（除其他外）互操作性协议、更好的鸭子类型支持和ndarray子类处理。

关键目标是：使为NumPy编写的代码也能与其他类似NumPy的项目一起工作。 这将使通过例如CuPy、JAX或PyTorch实现GPU支持，通过Dask实现分布式数组支持，以及编写与SciPy、scikit-learn和其他此类软件包配合良好的专用数组（从头开始或作为numpy.ndarray子类）成为可能。NumPy 2.0在采用并遵守数组API标准（v2022.12，参见NEP 47——采用数组API标准）方面取得了重大进展。未来这方面的工作将包括支持较新版本的数组API标准，并根据实际经验和需求添加所需的功能。

此外，__array_ufunc__和__array_function__协议在这里发挥作用——它们稳定且被多个下游项目使用。

性能#

改进NumPy的性能对许多用户都很重要。我们将此工作重点放在通用SIMD（参见NEP 38——使用SIMD优化指令来提高性能）内在函数上，这些函数通过抽象层在各种硬件平台上提供了不错的改进。基础设施已到位，我们欢迎后续PR来为相关的NumPy功能添加SIMD支持。

从C迁移到C++，无论是在SIMD基础设施中还是在NumPy内部更广泛地使用，都在进行中。我们还开始使用Google Highway（参见NEP 54——SIMD基础设施演进：迁移到C++时采用Google Highway？），并且这种使用可能会扩大。支持较新的SIMD指令集（例如arm64上的SVE）的工作正在进行中。

其他性能改进思路包括

  • 围绕并行执行的更好策略（相关的是对自由线程CPython的支持，见下文）。

  • 使NumPy能够对ufunc使用更快但精度较低的实现。到目前为止，唯一修改ufunc行为的状态是np.errstate。但是，NumPy 2.0对np.errstate和ufunc C实现的改进使得这种类型的添加更容易。

  • 各个函数中的优化。

此外，我们希望改进基准测试系统，包括覆盖范围、易用性和结果发布。与main分支相比，基准测试PR/分支是一个主要目的，对于侧重于性能的PR（例如，向函数添加SIMD加速）是必需的。此外，我们希望有一个像我们之前这里拥有的性能概述，以更易于长期维护的方式设置。

文档和网站#

NumPy文档的质量参差不齐。API文档状况良好；许多主题的教程和高级文档缺失或已过时。有关计划的改进，请参见NEP 44——重构NumPy文档。在numpy-tutorials repo中正在添加更多教程。

我们还打算使我们文档中的所有示例代码都具有交互性——正在通过jupyterlite-sphinx和Pyodide进行这方面的工作。

我们的网站（https://numpy.com.cn）状况良好。进一步扩展网站翻译的语言数量是可取的。通过JupyterLite改进交互式笔记本小部件也是如此。

可扩展性#

我们的目标是继续简化NumPy的扩展。这里的主要主题是改进dtype系统——例如，参见NEP 41——迈向新的数据类型系统的第一步及其链接的相关NEP。在NumPy 2.0中，用户定义dtype的新C API已公开。我们的目标是鼓励其使用并进一步改进此API，包括支持在Python中编写dtype。

可能首先在NumPy主存储库之外开发，并可能稍后上游到NumPy的新dtype的思路包括

  • 四精度（128位）dtype

  • 一个bfloat16 dtype

  • 支持编码（例如utf8或latin1）的定宽字符串dtype

  • 一个单位dtype

我们进一步计划根据需要扩展ufunc C API。这里的一种可能性是创建一个新的、更强大的API，以允许挂接到现有的NumPy ufunc实现中。

用户体验#

类型注释#

大多数NumPy功能的类型注释已完成（尽管一些子模块如numpy.ma缺少返回类型），因此用户可以使用mypy等工具来检查其代码类型，并且IDE可以改进其对NumPy的支持。正在改进这些类型注释，例如支持注释数组形状（参见gh-16544）。

平台支持#

我们的目标是增加对不同硬件架构的支持。这包括在 CI 服务可用时添加 CI 覆盖率，为需求足够高的平台提供 PyPI 上的轮子（例如，我们为 NumPy 2.0 添加了musllinux轮子），以及解决我们在 CI 中未测试的平台上的构建问题（例如，AIX）。

我们打算编写一份 NEP，涵盖我们提供的支持级别以及将平台提升到更高支持级别的要求，类似于PEP 11。

进一步改进提升和标量逻辑的一致性#

NumPy 2.0 修复了许多与提升相关的，特别是与标量相关的许多问题。我们计划继续修复剩余的不一致之处。例如，NumPy 将 0 维对象转换为标量，而 NumPy 仍然允许的一些提升是有问题的。

支持免线程 CPython#

CPython 3.13 将是第一个提供免线程构建的版本（即，禁用 GIL 的 CPython 构建）。目前正在进行的工作是为了在 NumPy 中很好地支持这一点。之后稳定并完成后，可能会有一些机会实际利用免线程 CPython 带来的性能改进潜力，或者使 NumPy 用户更容易做到这一点。

减小二进制文件大小#

从 PyPI 和其他平台下载 NumPy 的数量持续增长——截至 2024 年 5 月，仅从 PyPI 下载的数量就超过了每月 2 亿次。减小已安装 NumPy 包的大小有很多好处：更快的安装速度、更低的磁盘空间使用率、减轻 PyPI 的负载、更小的环境影响、更容易在资源受限的环境和平台（如 AWS Lambda）上安装更多软件包、降低 Pyodide 用户的延迟等等。我们的目标是大幅度减小尺寸，并使最终用户和打包人员更容易生成更小的自定义构建（例如，我们在 2.1.0 之前添加了在构建前去除测试的支持）。详情请参见gh-25737。

支持使用 CPython 的受限 C API#

使用 CPython 受限 C API，允许生成使用稳定 ABI 且独立于 CPython 功能版本的abi3轮子，这对于使用 NumPy C API 的下游软件包和 NumPy 本身都有好处。在 NumPy 2.0 中，已经完成了使用 NumPy 中的 Cython 支持来使用受限 C API 的工作（参见`gh-25531 <https://github.com/numpy/numpy/pull/25531`__）。需要更多工作和测试才能确保完全支持下游软件包。

我们还想探索 NumPy 本身使用受限 C API 所需的内容——这将使在整个生态系统中测试新的 CPython 开发版和预发布版本更容易，并显著减少 NumPy 本身的 CI 作业的维护工作。

为 NumPy 创建一个仅包含头文件的包#

我们已经将公共 NumPy 头文件中与平台相关的部分减少到了几乎为零。现在可以创建一个单独的包，其中只包含 NumPy 头文件和它们的发现机制，以便下游软件包能够在没有安装 NumPy 的情况下针对 NumPy C API 进行构建。这将使使用 NumPy 的 C API 更容易/更便宜，尤其是在我们不提供轮子的利基平台上。

NumPy 2.0 稳定性和下游使用#

我们在 NumPy 2.0 中进行了大量的更改（和改进！）。发布过程花费了很长时间，并且生态系统的一部分仍在追赶。我们可能需要放慢速度一段时间，并可能帮助生态系统的其余部分适应 ABI 和 API 的更改。

我们需要评估对 NumPy 本身、下游软件包作者和最终用户的成本和收益。基于该评估，我们需要得出关于将来是否现实地进行另一次破坏 ABI 的发布的结论。这还将影响我们 C API 的未来发展。

安全#

NumPy 非常安全——我们只收到少量关于潜在漏洞的报告，而且大多数报告都是不正确的。我们在已记录的安全策略、私下披露方法和维护 OpenSSF 成绩单（高分）方面取得了进展。但是，我们已经有一段时间没有改变我们处理供应链安全的方式了。我们的目标是在这里改进，例如实现所有发布的构建工件的完全可重复构建——并为它们提供完整的来源信息。

维护#

  • numpy.ma的状态仍然很糟糕，并且维护不足。它需要改进，想法包括：

    • 重写掩码数组，使其不再是 ndarray 的子类——也许在单独的项目中？

    • 将 MaskedArray 作为鸭子类型数组，和/或

    • 支持缺失值的 dtype

  • 制定一个关于如何处理 NumPy 和 SciPy 之间linalg重叠的策略。

  • 弃用np.matrix（非常缓慢）——一旦 SciPy 中从稀疏矩阵到稀疏数组的切换完成，这是可行的。

  • 为“矢量化索引”和“外部索引”添加新的索引模式（参见NEP 21 — 简化和明确的高级索引）。

  • 使多项式 API 更易于使用。