Pandas發展規劃

Pandas是一個功能強大的開源Python庫，用於數據分析，操作和可視化。 自2014年以來，我一直在教數據科學家使用pandas，從那時起，它已經越來越受歡迎，估計有500萬到1000萬用戶，並成為Python數據科學工具包中的「必須使用」的工具。

我是在版本0.14.0左右開始使用pandas，並且我已經關注了pandas庫，因為它的當前版本0.23.4已經非常成熟。 但是多年來，許多數據科學家都向我提出過這樣的問題：

• 「Pandas可靠嗎？」
• 「它將來會繼續工作嗎？」
• 「它有問題嗎？他們甚至沒有發布1.0版本！」

版本號可用於表示產品的成熟度，因此我理解為什麼有人可能會猶豫是否依賴「1.0之前的」軟體。 但在開源世界中，版本號並不一定能告訴你任何關於庫的成熟度或可靠性的信息。（是的，Pandas庫既成熟又可靠！）相反，版本號傳達了API的穩定性。

特別是，版本1.0向用戶發出信號：「我們已經弄清楚API應該是什麼樣子，因此只有主要版本（2.0,3.0等）才會發生API破壞性更改」，換句話說，版本1.0標誌著代碼永遠不應該僅僅因為升級到下一個次要版本就導致中斷。

所以問題仍然存在：Pandas1.0中會出現什麼，它什麼時候到來？

走向pandas 1.0

我最近觀看了Pyrad London的一個名為Towards pandas 1.0的演講，由Pandas核心開發人員Marc Garcia發表。 關於Pandas的未來，這是一個啟發性的討論，所以我想強調並評論一些提到的項目：

• 方法鏈
• inplace
• Apache Arrow
• 可拓數組
• 其他棄用
• 路線圖

如果你想跟隨完整的談話幻燈片，可以在這個Jupyter notebook中找到它們。（http://nbviewer.jupyter.org/github/datapythonista/towards_pandas_1/blob/master/Towards%20pandas%201.0.ipynb）

方法鏈

Pandas核心團隊現在鼓勵使用「方法鏈」。 這是一種編程風格，您可以將多個方法調用鏈接到一個語句中。 這允許您將中間結果從一個方法傳遞到下一個方法，而不是使用變數存儲中間結果。

以下是Marc實現的不使用方法鏈的示例：

以下是使用方法鏈的等效代碼：

他們更喜歡方法鏈的主要原因是：

• 可讀性：在他們看來，方法鏈更具可讀性。
• 性能：由於方法鏈提前告訴Pandas您想要做的一切，Pandas可以更有效地規劃其操作。

以下是我的想法：

• 多年來我一直在編寫簡短的方法鏈，我發現它們比替代方案更具可讀性。 例如，我絕不會通過使用中間變數將df.is.sum或ser.value_counts.sort_index分成多行代碼。
• 但是，我實際上發現長方法鏈（Marc的第二個例子）比其他方法更不易讀，但也許那是因為我不習慣寫它們。 具體來說，我很難搞懂assign方法中的lambda函數。

另一位pandas核心開發者Tom Augspurger也指出：

「過長鏈的一個缺點是調試可能會更難。如果最後出現問題，你就沒有中間值來檢查。」

需要明確的是，pandas一直提供方法鏈，但通過添加新的「可鏈式」方法，對鏈的支持有所增加。 例如，query方法（在上面的鏈中使用）之前在文檔中被標記為「實驗性的」，這就是為什麼我沒有使用它或教它。 該標籤已在pandas 0.23中刪除，這可能表明核心團隊現在鼓勵使用query。

我認為您不會被要求使用方法鏈，但我認為文檔最終可能會遷移到使用該樣式。

有關該主題的更長時間的討論，請參閱Tom Augspurger的Method Chaining帖子，該帖子是他的Modern pandas系列的第2部分。（https://tomaugspurger.github.io/method-chaining.html）

inplace

pandas核心團隊不鼓勵使用inplace參數，最終它將被棄用（這意味著「計劃從庫中刪除」）。 原因如下：

• inplace在方法鏈中不起作用。
• 與名稱所暗示的相反，使用inplace通常不會阻止創建副本。
• 刪除inplace選項會降低pandas代碼庫的複雜性。

就個人而言，我是inplace的粉絲，我喜歡寫df.reset_index（inplace = True）而不是df = df.reset_index。 話雖這麼說，許多初學者確實對inplace感到困惑，並且在pandas中有一個明確的方法來做事，所以最終我會同意棄用inplace。

如果您想了解更多關於如何在pandas中管理內存的話，我建議您觀看Marc演講的這個5分鐘部分。（https://www.youtube.com/watch?v=hK6o_TDXXN8&t=700）

Apache Arrow

Apache Arrow是一項「正在進行中的工作」，成為pandas的後端。 Arrow是由pandas創始人Wes McKinney在2015年創建的，用於解決pandas DataFrame的許多潛在局限性（以及其他語言中的類似數據結構）。

Arrow的目標是創建一個開放標準，用於表示原生支持複雜數據格式的表格數據，並針對性能進行了高度優化。儘管Arrow的靈感來自pandas，但它的設計目標是成為跨多種語言的數據科學工作的共享計算基礎架構。

因為Arrow是一個基礎設施層，它最終用作pandas後端（可能在pandas 1.0之後）對於pandas最終用戶來說理想上是透明的。但是，它應該會帶來更好的性能，並且支持在pandas中使用「大於RAM」的數據集。

關於Arrow的更多細節，我建議閱讀Wes McKinney 2017年的博客文章，Apache Arrow和「我討厭pandas的10件事」，以及觀看他在SciPy 2018上的演講（有幻燈片）。有關如何整合Arrow的詳細信息進入pandas，我建議觀看Jeff Reback在2017年PyData NYC上的演講（附幻燈片）。

可拓數組

Extension Arrays允許您創建用於pandas的自定義數據類型。該文檔提供了一個很好的總結：

Pandas現在支持存儲類似數組的對象，這些對象不一定是1-D NumPy數組作為DataFrame中的列或Series中的值。這允許第三方庫實現對NumPy類型的擴展，類似於pandas如何實現分類，具有時區的日期時間，句點和間隔。

換句話說，之前pandas團隊必須編寫大量自定義代碼來實現NumPy本身不支持的數據類型（例如分類）。隨著Extension Arrays的發布，現在有一個用於創建任何人都可以使用的自定義類型的通用介面。

pandas團隊已經使用此介面編寫支持缺失值的整數數據類型，也稱為「NA」或「NaN」值。以前，如果您將任何值標記為缺失，則整數列將轉換為浮點數。開發文檔表明「Integer NA」類型將在下一版本（版本0.24）中提供。

此介面的另一個引人注目的用途是本機字元串類型，因為pandas中的字元串當前使用NumPy的「對象」數據類型表示。 fletcher庫已經使用該介面在pandas中啟用本機字元串類型，儘管pandas團隊最終可能會將自己的字元串類型直接構建到pandas中。

要深入了解此主題，請查看以下資源：

• 可拓數組用於pandas：博客文章關於使用可拓數組開發cyberpandas。
• 使用自定義類型擴展pandas：關於「整數NA」類型開發的視頻（帶幻燈片）。
• 使用Apache Arrow和Numba擴展pandas：視頻（帶幻燈片）通過fletcher開發字元串類型，使用Arrow來存儲和Numba來獲得更好的性能（如此處所述）。

其他棄用

以下是談話中討論的一些其他棄用：

• ix訪問器已在0.20版本中棄用，支持loc（基於標籤的訪問）和iloc（基於位置的訪問）。
• 在版本0.20中也棄用了三維數據的Panel數據結構，而支持具有MultiIndex的DataFrame。
• 當DataFrame主要包含缺失值時，SparseDataFrame將在即將發布的版本中棄用。
• 將於2019年1月從pandas中刪除Python 2支持！

路線圖

根據談話，這是pandas1.0的路線圖：

• 0.23.4是最近發布的pandas（2018年8月）。
• 根據GitHub的里程碑，0.24的目標是2018年底。
• 0.25是針對2019年初的目標，它將警告1.0中的所有棄用。
• 1.0將與0.25相同，但將刪除所有已棄用的功能。

關於路線圖的更多細節可以在2018年7月的pandas衝刺記錄中找到，但所有這些計劃都可能有所變化。

英文原文：https://www.dataschool.io/future-of-pandas/

譯者：趙四妹

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！