[関西Kaggler会2025#2LT] 初学者+MLエンジニア対象！ モダンなPythonの書き方

Transcript

1. 初学者+MLエンジニア対象！ モダンなPythonの書き⽅ 関⻄Kaggler会 交流会 in Osaka 2025#2 @colum2131
2. ⾃⼰紹介 • ころんびあ (X: @colum2131) • チューリング株式会社 MLエンジニア • Kaggle Competitions Master • 最近⾞を買いました (MAZDA3)
3. Pythonの特徴 • ユーザー⽬線: Pythonは動的型付けのインタプリタ⾔語 👍 書きやすい、データ分析やMLにおいては豊富なライブラリが魅⼒ 👎 動的型付けのため意図しないバグが発⽣しやすい、実⾏速度が遅い def fn(a): return a + "1" • 引数はどういう型の変数を受け取る？ • 出⼒はどういう型になる？ a = 1 a = str(a) # "1" • 変数は型の制約を持たないため 別の型でも再代⼊可能
4. コードの可読性を上げる チームやAI Agentと作業するにあたってコードの可読性は重要 どういうことを意識するか？ • わかりやすい命名規則‧データ構造 • ⼀貫性のあるコード • ロジックの複雑度を下げる • コメントやドキュメントなどで伝える など プロジェクトで⼀貫すると👍
5. PEP 8 という公式のスタイルガイドを参考にする ⽤途 スタイル‧例 関数‧変数名‧モジュール名 全て⼩⽂字か_ (hello_fn, hello_module.py) クラス名 CapWords形式 (HelloManager) 定数名 全て⼤⽂字 (HELLO) インスタンスメソッド self 命名規則: PEP8による命名規則 など https://pep8-ja.readthedocs.io/ja/latest/
6. PEP8によるimportスタイル ライブラリのimport順も以下が推奨されます import⽂ は次の順番でグループ化すべきです: 1. 標準ライブラリ 2. サイードパティに関連するもの 3. ローカルなアプリケーション/ライブラリに特有なもの • ワイルドカードを⽤いたimport ( from <module> import *) は避けるべき • import⽂は通常⾏を分ける https://pep8-ja.readthedocs.io/ja/latest/ より引用 import os import sys from .module import fn_1, fn_2 👍 👎 1つのmoduleから複数importする場合は👍 import os, sys
7. • インデントは4つのスペースを使う (タブよりもスペースが好ましい) • 1⾏の⻑さは最⼤79⽂字に制限し、docstringは72⽂字まで • 関数やクラスは2⾏ずつあげて定義する • 式や⽂中の空⽩⽂字のスタイルを揃える: ◦ 👍 spam(ham[1], {eggs: 2}) 👎 spam( ham[ 1 ], { eggs: 2 } ) • None のようなシングルトンを評価するときは is か not is を⽤いる ◦ if not var is None よりも if var is not None を⽤いる • コードと⽭盾したコメントを書かない など PEP8のその他のスタイル
8. PEP8に全て遵守すべきか？ • PEP8 はCPythonや標準ライブラリの設計には厳守されている • ⼀⽅で必ずしもPEP8を遵守する必要はなく、⼀貫したチーム規約や 歴史的経緯によって困難な場合などがあればその限りではない • デフォルトのコーディングスタイルとして採⽤すると👍 unslothai/unsloth • passでコードブロックを表現 commaai/openpilot • インデントをスペース2つ ⼀⾏160⽂字で制限
9. コーディングスタイルが覚えられない...? 機械的に解析するツールとしての Linter と Formatter を使おう！ Linter (リンター) とは？ • ソースコードを静的解析して潜在的なバグ、コード規約の違反などを ⾃動的に検出して警告してくれるツール Formatter (フォーマッター)とは？ • ソースコードをスタイルガイドに基づいて⾃動的に整えるツール 代表的なlinter / formatter: • PEP8に従ったformatterのblack • import順をチェックするisort • PEP8に準拠したかチェックするpycodestyleを内包したflake8 など
10. #ruffに全部賭けろ • ruffはblackやisort, flake8などのlinter/formatterの機能を包括したツール • ⾮常に⾼速で、後述する静的型チェックツールとruffがあればOK • uvであれば uv add ruff --dev または uvx ruff でインストールおすすめ • ruff format でformat, ruff check でlinterを実⾏( --fix をつけると整形も) https://docs.astral.sh/ruff/
11. 先に #uvに全部賭けろ • uvはruffと同じAstral製のPythonプロジェクト管理ツール • 依存解決が⾼速でPythonのバージョン管理も可能→単⼀のツールでOK！ インストール(mac / Linux): curl -LsSf https://astral.sh/uv/install.sh | sh • uv init でプロジェクトを作成して uv sync で仮想環境(.venv)を作成する • パッケージのインストールは uv add <package名> (または uv pip install ) https://zenn.dev/turing_motors/articles/594fbef42a36ee pyproject.toml ←これを使います
12. ルールを.tomlにまとめる • ruffのルールはruff.tomlやuvで作成した pyproject.tomlに記載することが可能 ◦ *.line-lengthで1⾏の⻑さ ◦ *.lint.selectで守るルール ◦ *.lint.ignoreで無視するルール ◦ *.format.quote-styleで"か'を採用 など • ルールは公式ドキュメントを参考して プロジェクトごとに最適なルールを設定！ pyproject.toml https://docs.astral.sh/ruff/rules/
13. 型タイプヒント • Python 3.5 から型ヒントサポートとしてtypingが追加されて、 Python 3.8 以降にも段々と新しい型ヒントが追加👏 ◦ 詳細な各型ヒントは省略します ◦ typing.List → list, Union[<type>, <type>]→ <type> | <type> • 以下のようにアノテーションすることが可能 • ⼀⽅で引数がstring型以外でもエラーや警告は出⼒しない😢 • → 静的型チェックツールや実⾏時型検証のデータ構造を使おう！ def fn(a: str) -> str: return a + "1" 引数がstring型 返り値もstring型であることがわかる！
14. 静的型チェック: mypy • 静的型チェックツールとしてよくmypyが採⽤されます • uvであれば uv add mypy --dev または uvx mypy でインストールおすすめ • mypy <file名>または<ディレクトリ>で実⾏ def fn(a: str) -> str: return a + "1" fn(1) error: Argument 1 to "fn" has incompatible type "int"; expected "str" [arg-type] Found 1 error in 1 file (checked 1 source file) これをmypyでチェックすると怒ってくれる👏 Success: no issues found in 1 source file 正しいと以下のように出⼒:
15. 静的型チェック: mypyのルールをtomlに書く • mypyの設定もpyproject.tomlに書くことが可能 ◦ 同じスコープ内の変数の再定義を禁⽌するか ◦ 型注釈がないメソッドの定義を禁⽌するか など、細かくルールを決めることができる • 各設定は公式ドキュメントかCADDiの以下資料オススメ https://caddi.tech/archives/4506 pyproject.toml
16. 他の静的型チェックツール: pyrightやty • mypyに全部掛けるべきか？→今のところノー ◦ mypyは解析に時間がかかり⼤規模なプロジェクトだとストレスになる ◦ pyrightなど成熟した静的型チェックツールもある • ruffと同じAstral製のツールとしてtyが最近登場 ◦ ⾮常に⾼速 (mypyの10~100倍) ◦ まだα版であり今後の開発に期待 ty check <file名>または<ディレクトリ>で実⾏
17. jaxtypingを⽤いたテンソルのshape定義 特に深層学習では⼊⼒のテンソルが何を意図しているのかわかりにくい... → jaxtypingだとテンソルの型とshapeのヒントを付けられます！ • 引数として期待するテンソルのshapeがわかる！ • JAX以外にもnumpy.ndarray, torch.Tensorなども👍 • 動的検証も⼀応可能だが個⼈的にはコメントとして使⽤ nerfstudio-project/nerfstudioでも使用！ わかりやすい！ https://github.com/nerfstudio-project/nerfstudio/blob/2adcc380c6c846fe032b1fe55ad2c960e170a215/nerfstudio/model_components/renderers.py#L71C1-L79C33
18. データクラスとは何ぞや Python 3.7からdataclassデコレータが登場しました これがこう書けます
19. データクラスは何が嬉しい？ • 型アノテーションが必須になる → 静的型チェックと組み合わせることで保守性が⾼まる！ • __init__()コンストラクタを⾃動的に実⾏してくれる • ⾼機能なデータ構造としての設定ができる ◦ frozen=True でイミュータブルにできる • dictで保存するよりも型ヒントがあるデータ構造が可読性が⾼い • 実⾏時型検証はしないためその場合はpydanticなどを使うのがオススメ
20. 例えば物体認識した結果を使う時 わかりやすい
21. pre-commitを使おう git commit 時に定義したフックを実⾏して lint / format を実⾏するツール • uv add pre-commit --dev または uvx mypy おすすめ • pre-commit install を実⾏すると git commit時にフックが実⾏ • pre-commit run でも実⾏可能 • ruffやmypyなどは公式で pre-commit hookが提供されている • pre-commit⾃体もチェックする ◦ ファイルサイズの確認 ◦ ファイルの最後に改⾏があるか • タスクランナーとして使うの好き .pre-commit-config.yaml
22. コンペで可読性の⾼いコード書くべきか 個⼈的なお気持ち • 短期間で、かつソロで取り組むデータ分析コンペにおいて linter / formatter は開発速度を遅くする可能性があります。 • コンペにおいて導⼊するかは個⼈的にはどっちでもいいと思いますが AI Agent を導⼊する場合はマストで⼊れるべきだと思います。 • lint / formatをコード⽣成時に実⾏するようにルールに記載すると👍