The Zen of Python

技術

TL;DR

「Pythonの心構え(The Zen of Python)」というものがあるけど、プログラミングの心構えだよね、というお話。

Pythonの心構え

Pythonには「The Zen of Python」というものがあるそう。Zenとは「禅」のこと。外国のコンピュータエンジニアやプログラマ界隈で禅が好きな人多いですよね。色々解釈があると思いますが、意訳すると「Pythonの心構え」みたいな感じでしょうか。

で、これが原文。

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!

The Zen of Python

ちなみに、この原文は「PythonZen&PEP8認定試験」という試験の案内サイトで見つけたもの。当然、日本語で書かれているサイトなのですが、リンクは英語の原文で、日本語訳へのリンクはなかったりします。探せば日本語訳は色々出てきます。が、この「禅」に関する質疑応答なども考慮した日本語訳と解説が以下にあるので、この駄文を読んでる暇があればこちらを読んだほうがためになります。以下、日本語訳文については以下サイトから引用させていただきます。

別にPythonに限った話ではないよね

中身の詳細な解説はちゃんとしたサイトに任せます。が、言いたかったのはこれってプログラミング全般に通じるよね、ということ。

妥当なら選択肢は少ない方がよい

もっとも、いくつかの項目は別のプログラミング言語の考え方と正反対だったりするものもあります。一番わかりやすいのは「There should be one– and preferably only one –obvious way to do it.(何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。)」

上述のサイトではC++を例に挙げています。他のサイトではPerlを挙げていました。Perlは同じことでもいろいろなやり方があるという考え方です。他にもそういう考え方の言語は多いです。

ただ、最近は型にはめるような言語が増えてきているようにも感じます。昔はプログラマが自分の書きたいように好きに書けるべきという考え方だったのが、こういう処理ならこうとしか書けない、という感じに移り変わってきているよう。

まあ、歴史は繰り返すのでまた多様性を追求する言語が流行るかもしれませんけど。

暗黙の仕様は問題を引き起こす

他には「Explicit is better than implicit.(暗示するより明示するほうがいい。)」なども。以前は明らかなものはいちいち明示するのは手間だから、適切に言語処理系(やFW)が補った方がよいという考え方が広がった時期もありました。でも、それが理解不足の勘違いで不具合の要因になることも多いですよね。それならちゃんと書いた方がよいというのは自分も同意。

上述のサイトではPHPの暗黙の型変換を例に挙げてます。これ某RPAツールにも同じ問題がありました。何が困るって、1月18日のつもりで「1/18」や「1-18」みたいな文字列を変数に代入すると、それを数値として計算してしまうのです。よかれと思ってやったのでしょうが、正直、余計なお世話。そのためか、バージョンが新しくなったらこの仕様が変更されていました。

が、それはそれで大問題。上記の仕様をアテにしてコーディングされていた部分が、軒並み書き換えが必要になってしまったのです。ま、メジャーアップデートだったので他にも下位互換のない変更を派手にやらかしてくれていたので、目の前が真っ暗になりました。

いや、自分の書いたののが動かなくなるのはまだよいのです。が、当時の自分はこのツールをグループ各社に推進する立場。いくつかの会社で導入していたのですが、もう自分のせいでもないのに平謝りです。挙句に、移行期間に制限があったり、移行のための代替ライセンスの提供もしてくれなかったりと問題も多かったため、代理店経由で開発元に「ふざけんな、商売やる気あんのか?アーン?」という内容をオブラートに包みまくって送りつけたくらいです。

かなり脱線しましたが、暗黙で動くものってハマれば便利なのですが、別の視点で見ると問題を引き起こしたり、後になって困ることになりがちということです。

プログラマは自分の意図を明示することが不具合を少なくするたったひとつの冴えたやり方かと。

プログラミングはゆとりが欲しい

日本の教育は一時詰め込み教育で、その反動としてゆとり教育なんてものが生まれました。が、それはそれで急に180度転回したものですから、後になってそれはそれで「ゆとり世代」なんて呼ばれる可哀想な世代が生まれてしまいました。

それはさておき、プログラミングでもやたらと詰め込んで行数を少なくしようとする方々が結構います。それを戒めているのが「Sparse is better than dense.(密集しているよりは隙間があるほうがいい。)」でしょう。

確かに、コンピュータが非力な頃は、そういうテクニックがあったのも確か。でも、上記のサイトでもこんなコードではなく、

if i>0: return sqrt(i)
elif i==0: return 0
else: return 1j * sqrt(-i)

こういうコードにすべきと説明しています。

if i > 0:
    return sqrt(i)
elif i == 0:
    return 0
else:
    return 1j * sqrt(-i)

なんか、詰め込んで物理的に行数を短くすることがテクニックだという考えの人が少なくないようで。

なお、上記サイトでは上のコードよりしたのコードのほうが読みやすいよね、という立場。ですが、おそらく上の書き方をする人は「こっちのほうが読みやすい」と考えていそう。結局は主観なのでどちらが正しいと言い切れるものでもないのです。「条件: その時の処理」だよねと言われたら、それはそれで正しい気もしますし。

それに対する個人的な回答は「処理が複数行になる時と一行の時で書きっぷりを変えるのはよろしくない」です。余計な判断をするよりは必ず下のような書き方にするほうがわかりやすいという考え方になります。これは「やり方はひとつだけにすべき」という戒めにもつながります。

他にも省略できる括弧は絶対書かない的な人も居ます。自分は逆に冗長でも括弧を書く派。演算の優先順位とかをきちんと覚えればよいだけの話です。が、そこでちょっと止まって考えるくらいなら、冗長でも括弧を付けて自分の意図を明確にすべきと考えています。

文法を覚えるだけでなく、作法も学んでほしい

こんな駄文を書いているのも、なんかプログラミングを学ぶことがプログラミング言語の文法を覚えることと勘違いしてるんじゃないかな?という感じのものがあちこちで散見されるため。

質問サイトにいけば「今いけてるプログラミング言語はどれ?」みたいな質問が多いし、TwitterのTLを見てても「今は〇〇言語が来てる!」みたいなもんばかり。プログラミング言語にしろ、MWにしろFWにしろ、ライブラリにしろ、適切なものを適切な時に適切に使うだけなのに、なんか「これさえあれば万能」というものを求める人がなんと多いことか。銀の弾丸はないというのは、とうの昔に真理として認識されたはずなのに。

コーディング規約を定めた文書(PEP 8)でも「コードは書くよりも読まれることの方が多い」とあります。ガイドラインや規約を無批判に盲目的に受け入れる必要はありません。どうコードを書くかということを重視するのはわかりますが、読む時のことを考えて書くべきかと思います。

そんなわけで、文法を覚えるのもよいですが、作法についてもちゃんと学んで欲しいなと。その一つとして「The Zen of Python」はPythonを知らなくても、使うつもりがなくても、押さえておいて欲しいというお話でした。

技術Python

Posted by woinary