fastcore v2で変わったPythonの道具箱: Lと関数アダプター

v2で最初に確認する破壊的変更

fastcore v2ではPython 3.11以降が必要です。fastcore.scriptのParamは削除され、docmentsまたはtyping.Annotatedを使います。Lのstarmapやstarfilterなどはstarとrstarの関数アダプターへ置き換えられ、dspreadはdstarへ改名されました。旧APIが必要ならfastcore<2へ固定します。

移行前にfrom fastcore.utils import *やfastcore.allの利用箇所だけでなく、Param、star系メソッド、async helperのimportを検索します。importが通ることだけでは挙動互換を確認できないため、CLI引数と非同期処理の実行結果を旧版と比較します。

fastcoreの確認では、READMEに書かれた対象を一度に広げず、1番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。fastcore固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

Lがlistをどう広げるか

Lはlistの置き換えとして、コレクションによるindex、map、filter、unique、メソッドチェーンを提供します。READMEの例ではL(1,2,3,4)へx[[0,3]]、map、filter、uniqueを適用しています。listらしさを残しつつ、複数要素操作を短く書く設計です。

既存関数へ渡すときは、Lが期待される型と一致するか、空入力、ネスト、スライスで結果がどうなるかをテストします。便利な表記が増えるほど、標準listとの境界を暗黙にしないことが保守上のポイントです。

fastcoreの確認では、READMEに書かれた対象を一度に広げず、2番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。fastcore固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

patchとstore_attrの読みやすさ

@patchはサブクラス化せず既存クラスへメソッドを追加し、store_attrは__init__で引数を属性へまとめて保存します。delegatesは**kwargsを明示的なパラメータへ置き換え、IDE補完とドキュメントを改善します。いずれもPythonの動的性質を利用するため、定義時の効果を理解して使う必要があります。

小さなクラスでpatch後の属性とメソッドを確認し、pickle、multiprocessing、型チェックを使う場合は別テストを置きます。delegatesでは生成されたsignatureと実際の既定値を確認し、API文書だけが正しく見える状態を避けます。

fastcoreの確認では、READMEに書かれた対象を一度に広げず、3番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。fastcore固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

parallelとaioの移動

ThreadPoolExecutorとProcessPoolExecutorを拡張し、並列処理を簡略化します。v2ではrun_sync、iter_sync、ctx_syncなどがfastcore.aioへ移り、maybe_awaitやthenなども同モジュールに集約されました。READMEはProcessPoolExecutorのinitializerパターンを代替として示します。

CPU処理ではプロセス数とinitializerの副作用、IO処理では例外とキャンセルを確認します。旧netやxtrasからのimportを残したまま移行すると、名称変更ではなくモジュール移動が原因で失敗するため、import経路をテスト対象に含めます。

fastcoreの確認では、READMEに書かれた対象を一度に広げず、4番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。fastcore固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

テスト・Path・CLIの実用面

fastcore.testのtest_eq、test_ne、test_closeは読みやすいアサーションを提供します。拡張Pathにはlsやread_jsonがあり、dict2obj、obj2dict、compose、maps、filter_ex、timed_cache、fastcore.scriptもREADMEの対象です。機能は小さな補助に分かれており、必要な部分だけ導入しやすい構成です。

インストールはconda install fastcore -c fastaiまたはpip install fastcore、開発版はpip install -e ".[dev]"です。Ubuntu、macOS、Windowsでテストされるとありますが、使うPython版と依存版を固定し、CLI生成とread_jsonの最小例を実行して確認します。

fastcoreの確認では、READMEに書かれた対象を一度に広げず、5番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。fastcore固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

Apache-2.0と利用判断

fastcoreはApache License 2.0です。Pythonの標準機能を短い記法で拡張し、fastai周辺のコードや小さなCLIを整理したい人には向きます。v2の変更を受け入れられない既存コードでは、旧版固定が現実的です。

READMEは速度向上や安全性を保証していません。特にpatch、動的signature、並列実行は便利さとデバッグ負担が同居します。Python 3.11以降へ移行できるか、旧APIを使う箇所が残っていないか、三つの最小テストで確かめてから採用範囲を決めます。

fastcoreの確認では、READMEに書かれた対象を一度に広げず、6番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。fastcore固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

編集部の結論

fastcoreは、READMEに記載された構成と用途が自分の環境に合う人向けです。合わない人は採用すべきではありません。先にfastcoreのREADMEにある具体的な入力、出力、設定、実行経路を小さな検証環境で確認し、未記載の保証を補って考えないでください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes