ロードマップ

このページでは、pandas の開発における主要なテーマの概要を説明します。これらの各項目は、実装に比較的大量の労力を必要とします。これらは、専用の資金提供やコントリビューターからの関心があれば、より迅速に達成できる可能性があります。

ロードマップに載っている項目は、無制限の資金があったとしても、必ずしも実現するとは限りません。実装期間中に、機能の採用を妨げる問題が発見される可能性があります。

さらに、ロードマップに載っていない項目であっても、pandas に含まれる可能性がないわけではありません。ロードマップは、開発者の時間で数ヶ月から数年かかる可能性のある、プロジェクトに対する大規模な根本的な変更を対象としています。範囲の小さい項目は、引き続き課題トラッカーで追跡されます。

ロードマップは、PDEP と呼ばれる主要な機能強化提案のセットとして定義されています。PDEP の詳細、およびその提出方法については、PEDP-1を参照してください。

PDEP

議論中

承認済み

実装済み

却下済み

PDEP 待ちのロードマップポイント

拡張性

Pandas の extending.extension-types は、カスタムデータ型と配列ストレージで NumPy 型を拡張することを可能にします。Pandas は内部で拡張型を使用し、サードパーティライブラリが独自のカスタムデータ型を定義するためのインターフェースを提供します。

pandas の多くの部分は、意図せずデータを NumPy 配列に変換してしまいます。これらの問題は、ネストされたデータで特に顕著です。

ライブラリ全体で拡張配列の処理を改善し、NumPy 配列の処理との整合性を高めたいと考えています。これは、pandas の内部をクリーンアップし、拡張配列インターフェースに新しいメソッドを追加することで実現します。

文字列データ型

現在、pandas はテキストデータを object -dtype の NumPy 配列に格納しています。現在の実装には2つの主要な欠点があります。1つ目は、object -dtype が文字列に特化していないことです。任意の Python オブジェクトを object -dtype 配列に格納できます。2つ目は、効率的ではないことです。NumPy のメモリモデルは、可変幅のテキストデータに特に適しているわけではありません。

最初の問題を解決するために、文字列データ用の新しい拡張型を提案します。これは当初はオプトインで、ユーザーは明示的に dtype="string" を要求します。この文字列 dtype のバッキング配列は、当初は現在の実装である Python 文字列の object -dtype NumPy 配列になる可能性があります。

2つ目の問題 (パフォーマンス) を解決するために、代替のインメモリ配列ライブラリ (例: 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. 検証を一般的な機能 (例: キー/インデックスの dtype/構造) に限定するか、

  3. 実際のインデックス作成のために結果を再利用する。

  4. インデクサーは、他のインデクサーへの明示的な呼び出しに依存してはなりません。例えば、.loc のいくつかの内部メソッドが __getitem__ (またはそれらの共通の基底クラス) のいくつかの内部メソッドを呼び出すことは問題ありませんが、.loc のコードフローで the_obj[something] が現れてはなりません。

  5. 位置インデックス作成の実行は、ラベルを含んでいてはなりません (残念ながら、現在そうなっています)。つまり、.iloc へのゲッター呼び出し (または右辺が非インデックスの場合のセッター呼び出し) のコードフローは、オブジェクトの軸に一切関与してはなりません。

  6. インデックス作成は、値へのアクセス/変更 (つまり、._data または .values への操作) を複数回行ってはなりません。したがって、以下のステップは明確に分離される必要があります。

  7. 各軸でアクセス/変更する必要がある位置を見つける

  8. (アクセスしている場合) 返す必要のあるオブジェクトの型 (次元数) を導出する
  9. 実際に値にアクセス/変更する

  10. (アクセスしている場合) 返されるオブジェクトを構築する

  11. 4.i と 4.iii の分離の結果として、データがどのように保存されるかを扱うコード (複数の dtype、スパースストレージ、カテゴリカル、サードパーティ型などの処理の組み合わせを含む) は、影響を受ける行/列を識別するコードから独立しており、ステップ 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 コンパイラです。pandas がユーザー定義関数を受け入れる場所 (例: Series.apply、DataFrame.apply、DataFrame.applymap、および groupby と window コンテキスト) で、ユーザーが独自の Numba で jit された関数を適用する方法を提供したいと考えています。これにより、コンパイルされたコード内に留まることで、これらの操作におけるユーザー定義関数のパフォーマンスが向上します。

ドキュメントの改善

pandas のドキュメントの内容、構造、およびプレゼンテーションを改善したいと考えています。いくつかの具体的な目標には以下が含まれます。

パフォーマンス監視

Pandas は、パフォーマンスの回帰を監視するために airspeed velocity を使用しています。ASV 自体は素晴らしいツールですが、オープンソースプロジェクトのワークフローに統合するにはいくつかの追加作業が必要です。

現在 pandas のメンテナーで構成されている asv-runner 組織は、ASV の上に構築されたツールを提供しています。私たちは、いくつかのプロジェクトのベンチマークを実行するための物理マシンと、ベンチマークの実行を管理し、結果を報告するツールを持っています。

これらのツールを改善し、メンテナンスに資金を提供したいと考えています。