この記事の目的
2024年7月25日に merge されていた PR#58551 は PDEP-14: Dedicated string data type for pandas 3.0 というタイトルが示す通り pandas 3.0 に向けた string data type の仕様である。
翻訳は適宜DeepLやGPTにやらせておけばよいので、私が読んだ感想をparagraphごとにつらつらと記述していくお気持ち日記とする。（もやはそのようにしないと人間の価値が出せない時代となってしまった）
Disclaimer
この記事の内容は、私個人の意見や見解であり、私が所属する組織の公式な立場、方針、意見を反映するものではありません。この記事の内容について、組織はいかなる責任も負いません。
概要
- StringDtype(storage="pyarrow"|"python", na_value=np.nan|pd.NA)と 2x2の4通りの指定ができるようになる
- "str" 指定 は StringDtype(na_value=np.nan) と同値（pyarrowがインストールされていればそれ、そうでなければpythonが使われる）
- "string" 指定は StringDtype(na_value=pd.NA) と同値（pyarrowがインストールされていればそれ、そうでなければpythonが使われる）
- 文字列はオブジェクト型ではなくなるので、
ser.dtype == objectは3.0からエラーとなることに注意。object型の場合はNoneも欠損値として（ユーザーが意図して）使えたが、3.0からはNone自体持てなくなる -
GH-58613のコメントにあるように、 pyarrow の physical type は
pa.large_string()となるようだ(with StringDtype("pyarrow"), you always get pyarrow's large_string)
- 2.3.0リリースでは、将来のすべての文字列機能（デフォルトの文字列dtypeのpyarrowとobject-dtypeの両方）を利用できるようになる
感想
- Pandas 3.0 に向けての議論の発散があったが、このPDEP-14でstring typeの方針が決まったのは一安心
- PyArrow が必須でなくなったのは反対派の主張も強かったのであろう。pacakge サイズ増大のため、string type に限定して nanoarrow を使ってほしかった。（もちろん議論しており、可能性としては3.0リリース以降での議論となりそう
- break change を控えめにするため、引き続き NaN が missing value として使われる。これは一大決心して
NAに統一してほしかった。とはいえ保守的な立場を取らざるを得ないほど利用者が多いので一定理解はできる - また、NumPy 2.0 文字列 のbackend採用の可能性も残しつつあるこの選択は苦渋なものだったとも理解できる GH-58503
- StringDtype("pyarrow_numpy") はpandas 2.3でエイリアスとして非推奨となり、pandas 3.0で削除される。
StringDtype("pyarrow", na_value=np.nan)が明示的な指定となる
まずは2.3.0のリリースを待って、徐々に StringDtype(...) の明示的な指定に書き換えていくのが良さそう。
以上
参考