Open9

My Effective Python(ベストプラクティスとかではない)

ベストプラクティスではない.それどころか見方によっては悪なものも含むかもしれない、単なる個人の志向.
そもそもPython嫌いなのでPythonicとあまり相容れない

1. 辞書型リテラルより dict を使う

# bad
{
    'a': 2,
    'b': 'aaa'
}

# good
dict(a=2, b='aaa')

これはRubyで育った影響かもしれないが、キーを'"で囲むのが純粋に嫌い.同様の理由によりJSONが嫌い(関係ない).
以下のように、キーが変数名として使えない文字列の場合(実際ほとんどない)は諦めてリテラルを使う.

{
    'def': 2,
    'with space': 'aaa'
}

3. 標準ライブラリも場合によっては略称を使う

numpyという有名な数値計算ライブラリがあるが、ほとんどの人はimportするときに、import numpyではなくimport numpy as npとしている [要出典].このように、サードパーティのライブラリでは、公式ドキュメントにコードサンプルとして記述されている等の理由で、import ~ as ~が使われることが少なくない.
その一方で、標準ライブラリのドキュメントで import ~ as ~がコードサンプルとして記述されているのは(import自体の説明を除くと)あまり(全く?)ない.それゆえあまり一般的ではないのかもしれないが、自分は一部のモジュールについて決まった略称を用いている.

subprocess

# good
import subprocess as sp

# bad
import subprocess

# bad
from subprocess import run, DEVNULL

# not good
import subprocess
from subprocess import DEVNULL

subprocess.runくらいなら許せるが、引数にsubprocess.DEVNULLとかを渡すときに嫌になる.
かといって、かといってrunを直下にインポートしたくない.

typing

# good
import typing as t

# bad
import typing

# bad
from typing import Any, Dict, List, Union

typingを一々書いていると改行が増えるし、読みにくい.かといって個別にimportするには数が多すぎる.


argparse等他は多分していない.from hoge import fuga みたいな形で済むならその方がよいので.

新しいPythonだと list[str] や str | None のように書けるようになってきたので個別importでもいいような気もする。
(正直導入時からTypeScript参考にして | は入れておいて欲しかった。?は今でも欲しい)

4. 型ヒントは適当に

Pythonで型ヒントを頑張っても実りが少ないので、少しでも面倒だなと思ったらやらない.その労力はリファクタリングに向けた方がよい.

5. "より'

# good
'aaa'

# bad
"aaa"

'"より認知負荷が小さいので.
f-stringで、{}の中にも文字列リテラルが入るようなとき、諦めて内側を"にする.{}の中が変わったときに、外側を変えたくなる書き方はおかしいので、他の書き方は却下.

# good
f'AAA: {os.environ["AAA"]}'

# bad
f"AAA: {os.environ['AAA']}"

# bad
f'''AAA: {os.environ['AAA']}'''

flake8-quotes を使う

blackが"に直してくるので諦めつつある

作成者以外のコメントは許可されていません