路線圖

此頁面提供 pandas 開發中主要主題的概觀。這些項目中的每一個都需要相當大量的努力才能實作。這些項目可能會在有專用資金或貢獻者的興趣下更快達成。

項目在路線圖上並不表示它一定會發生，即使有無限的資金。在實作期間，我們可能會發現問題，導致無法採用該功能。

此外，項目不在路線圖上並不表示它會被排除在 pandas 中。路線圖是針對專案較大、基本的變更，這些變更可能需要數月或數年的開發人員時間。範圍較小的項目將繼續在我們的問題追蹤器中追蹤。

路線圖定義為一組名為 PDEP 的主要增強提案。有關 PDEP 的更多資訊，以及如何提交 PDEP，請參閱PEDP-1。

PDEP

討論中

已接受

已實作

已拒絕

待 PDEP 的路線圖重點

可擴充性

Pandas extending.extension-types 允許使用自訂資料類型和陣列儲存空間來擴充 NumPy 類型。Pandas 在內部使用擴充類型，並提供介面讓第三方程式庫定義自己的自訂資料類型。

pandas 的許多部分仍會無意間將資料轉換為 NumPy 陣列。這些問題在巢狀資料中特別明顯。

我們希望改善整個程式庫中擴充陣列的處理方式，使其行為更符合 NumPy 陣列的處理方式。我們將透過清理 pandas 的內部結構，並為擴充陣列介面新增方法來達成此目標。

字串資料類型

目前，pandas 會將文字資料儲存在 object -dtype NumPy 陣列中。目前的實作有兩個主要的缺點：首先，object -dtype 並非專屬於字串：任何 Python 物件都可以儲存在 object -dtype 陣列中，而不仅仅是字串。其次：這並不有效率。NumPy 記憶體模型並不特別適合可變寬度的文字資料。

為了解決第一個問題，我們建議為字串資料提出新的擴充類型。這最初將是選擇性的，使用者必須明確要求 dtype="string"。支援此字串 dtype 的陣列最初可能是目前的實作：Python 字串的 object -dtype NumPy 陣列。

為了解決第二個問題（效能），我們將探討替代的記憶體中陣列函式庫（例如 Apache Arrow）。作為工作的一部分，我們可能需要實作 pandas 使用者預期的特定運算（例如 Series.str.upper 中使用的演算法）。該項工作可能會在 pandas 之外完成。

Apache Arrow 互操作性

Apache Arrow 是用於記憶體中資料的跨語言開發平台。Arrow 邏輯類型與典型的 pandas 使用案例緊密對齊。

我們希望在 pandas 中提供對 Arrow 記憶體和資料類型的更佳整合支援。這將使我們能夠利用其 I/O 功能，並提供與使用 Arrow 的其他語言和函式庫更好的互操作性。

索引和內部解耦

在 pandas 資料結構中取得和設定值的程式碼需要重新整理。特別是，我們必須清楚地將將金鑰（例如 DataFrame.loc 的引數）轉換為位置的程式碼與使用這些位置來取得或設定值的程式碼分開。這與建議的 BlockManager 重寫有關。目前，BlockManager 有時使用基於標籤而非基於位置的索引。我們建議它應該只使用位置索引，而將金鑰轉換為位置應完全在較高層級完成。

索引是一個複雜的 API，有許多細微差別。此重構需要小心和注意。下列原則應激勵索引程式碼的重構，並應產生更乾淨、更簡單和效能更好的程式碼。

  1. 標籤索引絕不可在一個軸上重複尋找相同的標籤。這表示任何驗證步驟都必須

  2. 將驗證限制在一般特徵（例如鍵/索引的資料類型/結構），或

  3. 重複使用實際索引的結果。

  4. 索引器絕不可依賴對其他索引器的明確呼叫。例如，.loc 的某個內部方法呼叫 __getitem__ 的某個內部方法（或其共同的基礎類別）是可以的，但 the_obj[something] 絕不可出現在 .loc 的程式碼流程中。

  5. 位置索引的執行絕不可涉及標籤（如目前令人遺憾地發生）。也就是說，對 .iloc 的 getter 呼叫（或右邊是非索引的 setter 呼叫）的程式碼流程絕不可在任何方面涉及物件的軸。

  6. 索引絕不可涉及存取/修改值（即作用於 ._data 或 .values）超過一次。因此，以下步驟必須明確解耦

  7. 找出我們需要在每個軸上存取/修改的位置

  8. （如果我們正在存取）推導我們需要傳回的物件類型（維度）
  9. 實際存取/修改值

  10. （如果我們正在存取）建構傳回物件

  11. 作為 4.i 和 4.iii 解耦的推論，任何處理資料儲存方式的程式碼（包括處理多重資料類型、稀疏儲存、類別、第三方類型的任何組合）都必須獨立於處理識別受影響列/欄的程式碼，而且只能在步驟 4.i 完成後執行一次。

  12. 特別是，此類程式碼很可能不應存在於 pandas/core/indexing.py 中

  13. ... 而且絕不可在任何方面依賴軸的類型（例如沒有 MultiIndex 特殊情況）

  14. 作為點 1.i 的推論，Index（子）類別必須提供個別方法，用於任何不包含實際查詢的標籤有效性檢查，另一方面，用於任何所需的標籤轉換/調整/查詢。

  15. 試錯的使用應受限制，且無論如何都應限制為只捕捉實際預期的例外（通常為 KeyError）。

  16. 特別是，程式碼絕不應在 try... exception 的 except 部分（故意）引發新的例外。

  17. 任何特定於設定項和取得項的程式碼部分都必須共用，且當預期行為有細微差異時（例如使用 .loc 取得會引發遺失標籤，設定仍不會），它們可以用特定參數管理。

Numba 加速運算

Numba 是 Python 程式碼的 JIT 編譯器。我們希望提供使用者套用自己的 Numba-jitted 函數的方式，其中 pandas 接受使用者定義的函數（例如，Series.apply、DataFrame.apply、DataFrame.applymap，以及在 groupby 和視窗內容中）。這將透過維持在編譯程式碼中來提升這些運算中使用者定義函數的效能。

文件改進

我們希望改善 pandas 文件的內容、結構和呈現方式。一些特定目標包括

效能監控

Pandas 使用 airspeed velocity 來監控效能退化。ASV 本身是一個很棒的工具，但需要一些額外的作業才能整合到開源專案的工作流程中。

asv-runner 組織目前由 pandas 維護人員組成，提供建立在 ASV 之上的工具。我們有一台實體機器，用於執行多個專案的基準，以及管理基準執行和報告結果的工具。

我們希望資助這些工具的改善和維護，以