Python 初心者向けのアレコレ

この言語、本当にふざけないで欲しい。

免責

社内向けなのか、社内での不満なのかはよくわからないが、広く一般に通用する内容だと思って書いてはいない。走り書き。

Global 環境の Python

複数の version の Python に PATH を通すのを今すぐやめろ。PATH の意味がわからないなら調べてくれ。何もわからないなら全ての Python を uninstall してから入れ直してくれ。WSL2 ごと入れ直してもいい。初心者が訳も分からず Python 環境を崩壊させる事案を可算無限回見た。Python を滅ぼそう。

PATH の通った global な Python と異なる version の Python を入れたい場合は適当な位置にインストールして、絶対に PATH を通すことなく、Poetry に poetry env use path/to/your-python3 で実行ファイルの位置を教えてあげて使ってくれ。まぁそもそもコンテナで開発していればこのあたりの悩みは全部無縁になるんだけどな。

慣習的な表記

プロンプト先頭の $ 等は実行時にタイプしないし、path/to/something は環境に応じて読み替えるし、command [--opt foo] の [] 内は optional で実際には [ および ] はタイプしない。あまりに常識で誰も書かないので書いた。動きません、そうですか。

開発環境

Windows の PowerShell を使うのをやめろ。あ、PyInstaller とかで exe 化が必要とかなら Windows 側で開発してね。

WSL2 を使ってくれ。WSL2 を使うなら /mnt/c 以下に Git repository を clone するな（File I/O が死ぬほど遅くなるぞ）。あと bash をカスタマイズする気がないなら雑に fish を入れると補助輪が付いてよい。最近は fish 向けの案内も充実してるしな（POSIX 非互換なのは頭に留めておくと良い）。プラスで starship prompt も入れておくと何も設定しなくてもまぁまぁな shell 環境が整うぞ。

Python versions

<= 3.8 は汎用パッケージの作者でもない限り使わなくていい。

3.9 なら AWS Lambda が公式にサポートしている。ちょうど builtin の tuple や list が型パラメタ [] を受け取るようになって typing モジュールからの import が大きく減るのが嬉しい version だ。AWS Lambda を Dockerfile から作るなら awslambdaric package を使えば一瞬だ。

3.10 なら AWS Lambda はサポートされないが、typing.Union から開放されて、かつ機械学習の多くの packages を使えるバランスの良さがあるぞ。

3.11 は機械学習系が厳しくなるが、動作が速いぞ。typing.Self も地味に嬉しいポイントだ。

Pip, Conda, venv

今すぐ使うのをやめろ。Poetry（または Pipenv）を使え。venv は global packages を隠さないし、その Python スクリプトが動くのはお前の環境だけだ。

Docker コンテナ内なら仮想環境は要らないってのはもしかするとそうかもしれないが、開発コンテナ内ではパッケージ管理が必要だから Poetry (pyproject.toml, poetry.lock) は必要だし、本番環境でも global な Python 環境を汚染して問題なく振る舞うとも限らないので、安全側に倒して仮想環境を作ってもいい（GitHub issue で議論されているが、使っていい派）。まぁ poetry config virtualenvs.create false とか適当な環境変数を設定すればどっちみち解決するけどな。Pip が好きで好きでたまらないなら Poetry で requirements.txt を生成したらええ。

パッケージ作者でもない限り pyproject.toml と一緒に poetry.lock も commit/push しようね。

Jupyter notebook

まぁ落書きにはいいけど Git で管理しづらいし、デバッグもしづらいし、レビューもしづらいので最終的には構造化した上で Python ファイルに書いてくれ。

公式ドキュメントの dataclass の使い方は読んでくれ。

型アノテーション

書け。コメントを書く前に関数やクラスのメンバに型を書け。型は statically checkable なドキュメントで、実装と乖離しないからだ。docstring は何をする関数か大まかに書いてあれば全然いい。docstring でダラダラ説明するより先に関数名や引数の名前で簡潔に説明しろ。あーでも T | None の None (implies default) の扱いは書いたほうが丁寧かもね。

公式ドキュメントの typing モジュールの説明は一通り全部目を通して損はない。あと collections.abc とかね。

Formatter/Linter

使え。どうしても嫌でない限り（VS Code なら）"FormatOnSave" を有効化してくれ。自分は逆転して SaveOnFormat になってる気がするので自動保存機能は使ってないし使う気にもならない。

安易に linter の警告を切ろうとするな。PROBLEMS の数は未熟さの指標だ。型を書かないのはもっとダメだけどな。

mypy はレガシー化してきているから stubgen をしたいとかでなければ pyright（同じことだが Pylance 拡張）の方が賢いのでこちらを使うと良い。

Dunder

概念については知っておいてね。

Docker

可用性を高めたいなら、使えるなら使った方がいいよ。USER は作成してね。まぁだいだい社内に参考実装が転がってるもんよ。

その他

公式ドキュメントを読め。なんでもいいから勉強しろ。Python をやめろ。
（機械学習ツール類のせいで逃げられない。助けて……。）
（単純に一個人としての強めのお気持ちを書いたけど、社内向けの参考資料としてしれっと出して良いものか一生迷っている。）