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 主存储库之外首先开发的新 dtype 的想法，并可能在以后上游到 NumPy，包括

  • 四精度 (128 位) dtype

  • bfloat16 dtype

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

  • 单位 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 用户更容易做到这一点。

二进制大小缩减#

NumPy 从 PyPI 和其他平台下载的数量持续增加 - 截至 2024 年 5 月，仅从 PyPI 下载就超过了 2 亿次/月。缩减已安装的 NumPy 包的大小有很多好处：更快的安装、更低的磁盘空间使用量、更低的 PyPI 负载、更小的环境影响、更容易在资源受限的环境和平台（如 AWS Lambda）中放置更多包在 NumPy 之上、更低的 Pyodide 用户延迟，等等。我们的目标是实现显着缩减，以及使最终用户和打包人员更容易生成更小的自定义构建（例如，我们在 2.1.0 之前添加了对剥离测试的支持）。参见 gh-25737 以获取详细信息。

支持使用 CPython 的受限 C API#

使用 CPython 受限 C API 允许生成 abi3 轮子，这些轮子使用稳定的 ABI，因此独立于 CPython 功能版本，这对使用 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 更易于使用。

本页内容