ロードマップ

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

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

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

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

PDEP

議論中

承認済み

実装済み

拒否済み

PDEP保留中のロードマップポイント

拡張性

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

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

ライブラリ全体で拡張配列の処理を改善し、その動作をNumPy配列の処理とより一貫性のあるものにすることを目指しています。これは、pandasの内部を整理し、拡張配列インターフェースに新しいメソッドを追加することで行います。

文字列データ型

現在、pandasはテキストデータを`object`-dtype NumPy配列に格納しています。現在の実装には、主に2つの欠点があります。まず、`object`-dtypeは文字列に限定されていません。任意のPythonオブジェクトを`object`-dtype配列に格納できます（文字列だけでなく）。第二に、これは効率的ではありません。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回以上調べるべきではありません。これは、検証ステップが次のいずれかを行う必要があることを意味します。

  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とウィンドウのコンテキスト）、ユーザーが独自のNumbaでJITコンパイルされた関数を適用する方法を提供することを目指しています。これにより、コンパイル済みコードの範囲内で留まることで、これらの操作におけるユーザー定義関数の性能が向上します。

ドキュメントの改善

pandasのドキュメントの内容、構造、プレゼンテーションを改善したいと考えています。具体的な目標としては、

パフォーマンス監視

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

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

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