『Effective Python 2nd ed.』項目4：C言語形式の書式化やstr.formatではなくフォーマット済み文字列を使おう

フォーマット済み文字列は単なる糖衣構文、そう思っていた時期が僕にもありました。

『Effective Python 2nd ed.』の続き

effectivepython.com

項目4は2版で新規に追加された項目で、文字列のフォーマットに関する指針について説明している。 Pythonで文字列フォーマットを行う方法として

• printf 形式の文字列書式化
• str.format()
• フォーマット済み文字列

があり、筆者は3.6で追加されたフォーマット済み文字列を推奨している。 もちろん、新しいからフォーマット済み文字列を使おうなどという安直な理由ではなく、それぞれ理由を述べているので議論できる。 printf 形式（C言語形式）は公式ドキュメントでも使わないほうがよいという旨の説明があるが、str.format() ではなくフォーマット済み文字列を使おうと踏み込んだのが筆者の主張である。

Python 3.6が登場した当時は、str.format() があるし、フォーマット済み文字列は便利だけとそんなに使わないだろうな、と思っていた。 つまり、最初は糖衣構文として捉えていた。 ところが、今ではフォーマット済み文字列しか使わないようになってしまった。 あまり手の込んだ書式化をやってこなかったので、筆者が論証しているようなケースにはまったことがそれほどないのであるが、それもフォーマット済み文字列の簡明さに助けられた結果なのかもしれない。

『Effective Python 2nd ed.』項目3：bytesとstrの違いを知ろう

Unicodeだがunicodeはない

『Effective Python 2nd ed.』の続き

effectivepython.com

実質的に初版のItem 3の続投であるが、初版はPython 2の文字列であるstrとunicode、Python 3のbytesとstrの違いを含めて説明があったが、 2版ではPython 3向けの説明に特化して更新された。 単純にPython 2向けの説明を削ったのではなく、システムのエンコーディングに関する注意が追加されている。

自分の手元のPC（Windows 10）の環境でエンコーディングを調べてみた。

> python -c "import locale; print(locale.getpreferredencoding())"
cp932

日本語圏のWindows OSのPCなのでcp932であった。

localeのドキュメントを読んで、getdefaultlocale()も試してみた。

>>> import locale
>>> locale.getpreferredencoding()
'cp932'
>>> locale.getdefaultlocale()
('ja_JP', 'cp932')

業務でも、お客さんの環境はWindowsでExcelでCSVファイル開くというシチュエーションは（日本だと）頻出どころか必ず遭遇する問題である。 しかもcp932にあってShift_JISにはない文字を使われるなど日常茶飯事である。 必ずしもUTF-8エンコーディングではないという現実を受け入れつつ、『Effective Python 2nd ed.』に書かれているアドバイスを実行していこう。

『Effective Python 2nd ed.』項目2：PEP 8スタイルガイドに従おう

言語に依存しない原則

『Effective Python 2nd ed.』の続き

effectivepython.com

これも初版からの続投であるが、コーディングスタイルを揃えるという話題はPythonに限らずどの言語でも重要なことである。 Pythonの場合、PEP 8という形で広く使われているコーディングスタイルがあるのでそれに従ったほうがいいよ、という話である。

最近使っているツールを振り返ってみる。 コードフォーマッターとしてBlackとisort、 静的解析としてflake8とmypy、 複雑度チェックにradonを採用している。 いずれも、「なるべく尊重しよう」ではなく、CIのステップの1つとして必ずチェックされるようにCIを設定している（使っているのはGitLab CI）。 そのため、機械的に判定できる部分で各々の好みが出ることはない。 ある程度の品質を保つことができている...と信じたいがこれらは最低限のものであり、 コードベースの品質を高めるには『Effective Python 2nd ed.』をさらに読み進めていくほかない。