Zen of Python がより良いコードの作成にどのように役立つか

Python コードの書き方を改善したいですか?ここでは、Python の Zen が最初の一歩を踏み出すのにどのように役立つかを説明します。

Python は非常に簡単に学ぶことができます。しかし、保守が容易な慣用的な Python 風のコードを記述することは、特に初心者プログラマーにとっては困難な場合があります。 PEP-20 では、ベスト プラクティスに準拠した Python コードを記述することの重要性を概説するティム ピーターズの詩「The Zen of Python」が紹介されました。

Python の Zen を読むには、Python REPL を開始して次を実行します。

 >>> import this

 The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

これまで見てきたように、Zen of Python の格言のほとんどは自明です。解釈する際に次の格言と組み合わせる必要がある格言もあれば、前の格言と矛盾する格言もあります。それにもかかわらず、『The Zen of Python』は楽しく、魅力的で、実用的な読み物です。

Python の禅を解釈する

Zen of Python には、Python でプログラミングするための 20 の指針があることが提案されました。しかし、これまでのところ格言は 19 個しかありません。それらについて見ていきましょう。

美しいほうが醜いよりも優れています。

この格言は、エレガントで Python 的なコードを書くことの重要性を強調しています。

次のコード スニペットにはコードの匂いがあります。

 def square(num):
    squares = []
    for i in range(num):
        squares.append(i*i)
    return squares

関数：

• 空のリストを初期化します
• 関数内にリストの末尾に要素を追加するループがあり、
• 最後にリストを返します

これ は 機能的には正しいですが、Python 的ではなく、保守が困難です。

ジェネレーターを使用すると、よりエレガントに記述することができます。上記の関数と同等のジェネレーター関数を次に示します。

 def square(num):
    for i in range(num):
        yield i*i

さらに良いことに、次のジェネレーター内包表現を使用することもできます。

 num = ...
squares = (i*i for i in range(num))

暗黙的よりも明示的な方が優れています。

コードを記述するときは、他の開発者やユーザーがコードの暗黙の動作やデフォルトの動作を推測したままにしないでください。明確にしてください。ワイルドカードのインポートの例を見てみましょう。

 from some_module import * # wildcard import
from some_other_module import *

result = some_function() # where did this come from?

ワイルドカードインポートの使用はできる限り避けてください。それは明示的ではなく非効率的だからです。他のモジュールから関数やクラスをインポートする場合は、具体的に指定してください。

 from some_module import this_function # explicit import

result = this_function() # we now know.

複雑なものよりもシンプルなものの方が優れています。

この格言は、コードをシンプルに保ち、不必要な複雑さを避ける必要があることを示しています。たとえば、文字列を反転したい場合は、次の再帰的ソリューションを実装します。

 def reverse_string(my_string):
  if my_string == "":
    return my_string
  else:
    return reverse_string(my_string[1:]) + my_string[:1]

これは機能しますが、よりシンプルで Python 的な方法があることを考えると、これはこの問題に対する過剰設計の解決策である可能性があります。

文字列スライスのアプローチは次のとおりです。

 >>> rev_string = my_string[::-1]
>>> rev_string
'nohtyP'

組み込みのメソッドと関数を使用したアプローチは次のとおりです。

 >>> rev_string = ''.join(reversed(my_string))
>>> rev_string
'nohtyP'

複雑であることは複雑であるよりも優れています。

それでは、Python の禅における次の格言は何を伝えているのでしょうか?

Python での文字列の反転は非常に単純な操作です。ただし、実際には、より複雑なロジックが必要になる場合があります。かなり単純な例を次に示します。

データベースに接続する必要があるとします。

• まず、toml 構成ファイルを解析して、データベースの構成情報を取得する必要があります。
• データベースコネクタがインストールされている必要があります。
• その後、データベースに接続するための関数を定義したり、接続エラーを予測したり、エラー処理を実装したりすることができます。
• 最後に、データベースに接続した後、クエリを実行できます。

これでも十分単純ですが、文字列の反転に比べてより複雑なロジックが必要です。しかし、それは複雑である必要があるという意味ではありません。組み込みモジュール コードの機能を効果的に使用し、他の開発者がコードを読み、理解し、貢献できるようにコードを編成することができます。

ネストされたものよりもフラットな方が優れています。

フラット構造は、入れ子構造よりも解析し、理解するのが簡単です。プロジェクトに取り組んでいると、別個のモジュールを作成して機能を分離したくなるかもしれません。ただし、粒度が多すぎると過剰になる可能性があります。

そうは言っても、多くの場合、フラットな構造を超える必要があるかもしれません。ただし、ネストが必要な場合でも、最小限に抑えてください。

以下に例を示します。

 from db_info.config.actions.parse.parse_config import parse_toml # too difficult to parse!
...

from db_config.parse_config import parse_toml # much better!
...

密であるよりも疎である方が優れています。

開発者の取り組みを始めたばかりの場合は、言語の機能の一部を使いすぎたくなるかもしれません。たとえば、リスト内包表記は Python 的ですが、必要な場合にのみ使用されます。

次の内容を見てください。

 prices_dict = {'melons':40,'apples':70,'berries':55}
items = [(fruit,price) for fruit in prices_dict.keys() if fruit.startswith('m') for price in prices_dict.values() if price < 50]
print(items)
# Output: [('melons', 40)]

リスト内包は密度が高すぎるため、解析するのが困難です。この場合、条件文と同等の for ループを使用すると読みやすくなります。 理解が難しいという意味です。 🙂

読みやすさが重要です。

常に読みやすいコードを作成する必要があります。コードの可読性を向上させる簡単な方法をいくつか紹介します。

• 説明的な変数名の使用
• 関数とクラスの docstring の追加
• 必要に応じてコードをコメント化する
• 関数の引数と戻り値の型の型ヒントを追加する

特別なケースは、ルールを破るほど特別ではありません。

できる限り、言語の規則と推奨されるベスト プラクティスに従う必要があります。

しかし、これはいつでも可能なのでしょうか？いいえ、だからこそ次の格言があります。

実用性は純粋さに勝りますが。

これは前の格言の続きです。言語のルールに従うことが推奨されますが、場合によっては、一部の原則に従わなくてもまったく問題ありません。

エラーは決して黙って通過すべきではありません。

Python ではランタイムエラーが非常に一般的です。良い習慣として、簡単な修正としてエラーを黙らせるのではなく、常にエラーを処理する必要があります。

さまざまなエラーの種類に応じて、適切なエラー処理を予測して実装できます。

 try:  
    # doing this
except ErrorType1:
    # do something
except ErrorType2:
    # do something else
...

単純な一般的な例外は避けるべきです。新しいバージョンの Python (Python 3.11 以降) では、 より高度な例外処理 を実行するための例外チェーンと例外グループがサポートされています。

明示的に沈黙させない限り。

これは前の格言に続きます。設計でエラーを抑制する必要がある場合、またはエラーを抑制できる場合は、明示的に実行する必要があります。

たとえば、データベースに接続するときに、無効な構成情報が原因で OperationalError が発生する可能性があります。カスタム構成を使用して接続してみてください。 OperationalError が発生した場合は、デフォルトの構成を使用してデータベースへの接続を試みてください。

 try:
   # connecting using custom config
except OperationalError:
   # connect using default config

曖昧な点に直面しても、推測する誘惑を断ってください。

Python の禅におけるこの格言は一目瞭然です。疑問がある場合は、推測しないでください。ただし、コードを実行して出力を確認します。次に、必要な動作が得られるかどうかに応じて、読みやすさを向上させるか、必要に応じてロジックを変更します。

ブール値のタプルを使用した次の簡単な例を考えてみましょう。

 >>> True, True == (True, True)
(True, False)
>>> True, (True == (True, True))
(True, False)
>>> (True, True) == (True, True)
True

それを行う明白な方法は 1 つ、できれば 1 つだけである必要があります。

特定のタスクを実行するには、推奨される Python の方法が 1 つだけ存在する必要があります。ただし、どのような問題に対しても、複数の解決策が考えられます。

単純な文字列反転の例でも、再帰的な解決策、文字列のスライス、 join() メソッドを検討しました。

全角ダッシュの使用法が一貫していないことを考えると、これは内輪のジョークでもあります。通常、前後にスペースを入れずに全角ダッシュを使用します。または、先頭と末尾の両方のスペースで使用します。

ここで私たちが推測できることは次のとおりです。 Python 的な物事の実行方法は 1 つだけであるべきであることを強調するこの格言自体は、2 つ以上の方法で記述できます。

ただし、オランダ人でない限り、その方法は最初は明らかではないかもしれません。

軽い調子で書かれていますが、これは Python の作成者である Guido Van Rossum (オランダ人) のことを指します。特定のタスクを達成するための (最も) Python らしい方法は、Python の作成者のみが自然に思いつくものです。

したがって、開発者にとって、言語の機能をうまく活用するには、経験と 経験から学ぶこと が必要です。

今は決してないよりは良いです。

Zen of Python の他のいくつかの格言と同様、この格言もいくつかの異なる方法で解釈できます。

1 つの解釈として、開発者としてプロジェクトのコーディングの開始を先延ばしにするのはよくあることです。プロジェクトの詳細を計画するのを待つよりも、今から始めることをお勧めします。

もう 1 つの考えられる解釈は、有限のステップ数で実行されて終了するコードのほうが、バグが多く無限ループに陥るコードよりも優れていることが多いということです。

決して今よりも良いことはよくありますが。

この格言は前の格言と矛盾しているように思えます。先延ばしにしない方が良いですが、それでも問題をよく考えて、それに応じてコードを設計する必要があります。

適切に考えずに、コードの臭いやアンチパターンに悩まされたモジュールをコーディングするのは悪い考えです。そのようなコードはリファクタリングや修正措置を実装することが難しいためです。

実装を説明するのが難しい場合、それは悪い考えです。

ロジックがどれほど複雑であっても、いつでも説明が簡単で理解しやすい形式で実装できます。

実装の説明が難しい場合は、おそらく不必要に複雑になっている可能性があります。コードは、理解しやすいように変更またはリファクタリングできます。

実装が説明しやすい場合は、それが良いかもしれません。

これは前の格言に関連しており、これも一目瞭然です。実装を簡単な言葉で説明できれば、それは おそらく 良いアイデアです。

なぜなら、実装を簡単な言葉で説明できるコードは、最小限の複雑さで読みやすく、理解しやすいものである可能性が非常に高いからです。

名前空間は素晴らしいアイデアの 1 つです。それをもっと実現しましょう!

Python では、名前空間内の名前を使用して、特定のスコープ内のオブジェクトにアクセスできます。たとえば、クラスを作成し、それをテンプレートとして使用して、クラスのインスタンスを作成できます。これで、インスタンス変数はすべてインスタンスの名前空間内に存在します。

これにより、異なる名前空間にあるオブジェクトを競合することなく同じ名前で使用できるようになります。ただし、これらは必要な場合にのみ使用し、コードの単純さと読みやすさが損なわれないようにする必要があります。

結論

このチュートリアルはこれですべてです。このガイドが、Zen of Python が Python のコード スタイルと優れたコーディング プラクティスをどのように重視しているかを理解するのに役立つことを願っています。コードを書けば書くほど、上達します。

簡潔で読みやすいコードの書き方を学ぶことに興味がある場合は、Python ワンライナーに関するこの記事をお読みください。