NumPy 路線圖#

這是我們將投入資源的任務和功能的即時快照。它可用於鼓勵和啟發開發人員，以及尋找資金。

互通性#

我們的目標是讓與 NumPy 互通變得更容易。有許多類似 NumPy 的套件為 Python 生態系統新增了有趣的新功能，以及許多以各種方式擴展 NumPy 模型的函式庫。NumPy 中促進與所有此類套件以及使用它們的程式碼互通的工作可能包括（除其他外）互通性協定、更好的鴨子型別支援和 ndarray 子類別處理。

主要目標是：讓為 NumPy 撰寫的程式碼也能與其他類似 NumPy 的專案搭配運作變得容易。 這將透過例如 CuPy、JAX 或 PyTorch 實現 GPU 支援，透過 Dask 實現分散式陣列支援，以及編寫特殊用途陣列（從頭開始，或作為 numpy.ndarray 子類別），這些陣列可以與 SciPy、scikit-learn 和其他此類套件良好地搭配運作。NumPy 2.0 在此領域向前邁進了一大步，採用並遵守了陣列 API 標準 (v2022.12，請參閱 NEP 47 — 採用 Array API 標準)。未來在此方向上的工作將包括支援較新版本的陣列 API 標準，並根據真實世界的經驗和需求新增所需的功能。

此外，__array_ufunc__ 和 __array_function__ 協定在此處發揮作用 - 它們是穩定的，並被多個下游專案使用。

效能#

提升 NumPy 的效能對許多使用者而言非常重要。我們已將此努力的重點放在通用 SIMD (請參閱 NEP 38 — 使用 SIMD 最佳化指令提升效能) 內建函數上，這些函數透過抽象層在各種硬體平台上提供良好的效能提升。基礎架構已到位，我們歡迎後續的 PR 為相關的 NumPy 功能新增 SIMD 支援。

無論是在 SIMD 基礎架構還是在更廣泛的 NumPy 內部，從 C 轉換到 C++ 的過程都在進行中。我們也已開始使用 Google Highway (請參閱 NEP 54 — SIMD 基礎架構演進：遷移至 C++ 時採用 Google Highway？)，並且這種使用可能會擴展。支援更新的 SIMD 指令集（例如 arm64 上的 SVE）的工作正在進行中。

其他效能提升的想法包括

  • 圍繞平行執行的更好方案（相關的是對自由執行緒 CPython 的支援，請參閱下文）。

  • 啟用讓 NumPy 能夠為 ufuncs 使用更快但精確度較低的實作的能力。到目前為止，唯一修改 ufunc 行為的狀態是 np.errstate。但是，隨著 NumPy 2.0 在 np.errstate 和 ufunc C 實作方面的改進，使得此類新增變得更容易。

  • 個別函數中的最佳化。

此外，我們希望在覆蓋率、易用性和結果發布方面改進基準測試系統。將 PR/分支與 main 分支進行基準測試比較是主要目的，也是以效能為重點的 PR（例如，為函數新增 SIMD 加速）的必要條件。此外，我們希望獲得像我們在 這裡 擁有的效能概觀，並以更易於長期維護的方式設定。

文件和網站#

NumPy 文件 的品質參差不齊。API 文件狀況良好；許多主題的教學課程和高階文件遺失或過時。請參閱 NEP 44 — 重組 NumPy 文件 以了解計畫中的改進。在 numpy-tutorials repo 中正在新增更多教學課程。

我們也打算使我們文件中所有範例程式碼都具有互動性 - 目前正在進行透過 jupyterlite-sphinx 和 Pyodide 實現此目標的工作。

我們的網站 (https://numpy.dev.org.tw) 狀況良好。進一步努力擴展網站翻譯成的語言數量是可取的。透過 JupyterLite 改進互動式筆記本小工具也是如此。

可擴展性#

我們的目標是繼續讓擴展 NumPy 變得更容易。此處的主要主題是改進 dtype 系統 - 例如，請參閱 NEP 41 — 朝向新型資料型別系統的第一步 以及從中連結的相關 NEPs。在 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 上提供 wheels (例如，我們為 NumPy 2.0 新增了 musllinux ones)，以及解決我們未在 CI 中測試的平台 (例如 AIX) 上的建置問題。

我們打算撰寫一份 NEP，涵蓋我們提供的支援層級，以及平台移至更高支援層級所需的要求，類似於 PEP 11。

進一步修正提升和純量值邏輯的一致性#

NumPy 2.0 修正了許多與提升相關的問題，尤其是在純量值方面。我們計畫繼續修正剩餘的不一致之處。例如，NumPy 將 0-D 物件轉換為純量值，而 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 wheels，這對使用 NumPy C API 的下游套件和 NumPy 本身都有好處。在 NumPy 2.0 中，已完成啟用將有限 C API 與 NumPy 中的 Cython 支援搭配使用的工作 (請參閱 `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 變得更容易/更便宜，尤其是在我們不提供 wheels 的更小眾平台上。

NumPy 2.0 穩定化與下游使用#

我們在 NumPy 2.0 中進行了非常大量的變更（和改進！）。發布過程花費了很長時間，並且部分生態系統仍在趕上。我們可能需要放慢速度一段時間，並可能協助生態系統的其餘部分適應 ABI 和 API 變更。

我們需要評估 NumPy 本身、下游套件作者和終端使用者的成本和效益。根據該評估，我們需要就未來再次進行另一次 ABI 破壞性發布是否切實可行得出結論。這也將為我們 C API 的未來演進提供資訊。

安全性#

NumPy 非常安全 - 我們僅收到少量關於潛在漏洞的報告，而且大多數報告都不正確。我們在記錄安全性政策、私人揭露方法和維護 OpenSSF 記分卡（具有高分）方面取得了長足進展。但是，我們在供應鏈安全方面的方法很長一段時間以來沒有太多變化。我們的目標是在此方面進行改進，例如為我們發布的所有建置成品實現完全可重現的建置 - 並為它們提供完整的出處資訊。

維護#

  • numpy.ma 仍然狀況不佳且維護不足。它需要改進，想法包括

    • 重寫遮罩陣列，使其不再是 ndarray 子類別 – 也許在一個單獨的專案中？

    • MaskedArray 作為鴨子陣列型別，和/或

    • 支援遺失值的 dtypes

  • 撰寫關於如何處理 NumPy 和 SciPy 在 linalg 方面的重疊的策略。

  • 棄用 np.matrix（非常緩慢地）- 一旦 SciPy 中從稀疏矩陣切換到稀疏陣列完成，這就是可行的。

  • 為「向量化索引」和「外部索引」新增新的索引模式 (請參閱 NEP 21 — 簡化且明確的高階索引)。

  • 使 polynomial API 更易於使用。