Pythonの設計哲学

原文: http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html
原文投稿者: Guido van Rossum

今後のブログのエントリーは、生々しいPythonの歴史の詳細に入り込んでいく予定である。しかし、それに触れる前に、私がPythonの設計や実装をしている時に、意志決定を助けてくれた哲学的なガイドラインについて詳しく説明をしていきたいと思う。

まず最初に、Pythonはもともと"スカンク・ワークス(社内の秘密裏のプロジェクトの意味)"として計画がスタートした。公式な予算などなかったし、私は素早く結果を出そうとしていた。マネジメントにプロジェクトのサポートを説得する、というのがその理由の一つである(そして、その目論見は達成できた)。このような状況から、時間を節約するためのルールがいくつか導き出された。

• 道理に叶うときはいつでも、他の場所からアイディアを借りてくる。
• 「物事は可能な限り単純化されるべきである。ただし、それ以上単純にしてはいけない」(アインシュタイン)
• 一つのことに集中する(UNIXの哲学)
• パフォーマンスについては気にしないで。必要であれば、後から最適化を行うので。
• 環境に戦いを挑むな。そして流れに身を任せよ。
• 完璧を求めようとするな。「十分に良い」で足りることがほとんどである。
• (それゆえに)たまに手を抜くのは問題はない。特に、後でやれば正しくできる場合には。

これ以外の原則は時間の節約を意図したものではなかった。たまに正反対なことを言っているものも含まれていた。

• Pythonの実装は特定のプラットフォームに縛り付けるべきではない。いくつかの機能が動作しないのは問題ないが、コアはどこでも動作すべきである。
• コンピュータが行えるような細かい仕事はユーザにさせてはならない。(私はいつもこの原則に従っていたわけではなく、後のセクションでこれの悲惨な影響についていくつか説明する)。
• プラットフォームに依存しないユーザコードをサポートし、また、そうなるように奨励すべきである。ただし、プラットフォームの能力や特性を生かすためのアクセスを妨げてはならない。(これはJavaとは対照的である)。
• 巨大で複雑なシステムは、さまざまな階層で拡張可能であるべきだ。きれいに拡張できる場合もあるだろうし、洗練したやり方ができないこともあるだろうが、これをすることで、ユーザが自分自身を助ける機会を最大限に増やすことができる。
• エラーは致命的であってはならない。エラーの状況であっても、バーチャルマシンの機能が壊れていなければ、ユーザコードはエラーから復帰できるようにすべきである。
• 同時に、エラーはこっそり握りつぶしてはならない。(実装時には、これらの２つの項目により、例外を使用するという意志決定が自然に行われた)
• ユーザのPythonコードのバグにより、Pythonのインタプリタが未定義な動作を起こしてはならない。コアダンプは、決してユーザの責任ではない。

最終的に、私は良いプログラミング言語設計のためのさまざまなアイディアを身につけることができた。このアイディアの多くを学んだきっかけは、私が初めて実際の言語の実装と設計を体験をしたABC(訳注：教育用のプログラミング言語の名前)のグループに参加したことである。これらのほとんどのアイディアは、エレガンス、シンプルさ、読みやすさなど、主観的な概念を中心に展開されているため、形式知に表出化するのが困難であった。

後ほど、ABCがPythonに与えた影響について詳しく述べるが、まずは読みやすさのルールについて説明してみたい。まず、句読記号文字は、一般的な英語的な記述や、高校レベルの代数に沿った、伝統的な使い方をすべきである。ただし、かけ算の"x*y"、配列アクセスの"a[i]"、属性アクセスの"x.foo"など、プログラミング言語の中で長い間使用されてきた表記法がある場合は例外とすることもある。ただし、Pythonでは変数を明示するために"$"を使用したり、副作用のある操作を明示するために"!"を使用することはない。

Tim Petersは古くからのPythonユーザである。最終的にもっとも多くのコミットをする、頼りになるコア開発者となった。彼は、私が言語化してこなかった設計原理を記録しようとして、"Zen of Python"(リンク先は英語)と呼ばれるものを作成した。全文を引用する。

• 醜さよりも美しさ
• 不言実行よりも有言実行
• 複雑よりもシンプル
• 入り組んだ１行よりも、複数行のコード
• 深い階層よりも平坦な階層
• 過密なコードよりも疎なコード
• 読みやすさに勝るものなし
• 「特別な場合」というのは言い訳にならない
• しかし、ルールに愚直であるよりは実用性
• 問題があるときには、こっそりと処理してはならない
• 隠すすることが明示されている場合を除いて
• 解釈が多数ある場合、推測でやってはならない
• 実現する方法は一つ、なるべく一つであるべきだ
• オランダ人※にしか明確でないこともありえるが
• 「実現してないいつか」 よりも「今」
• あわてて今やるよりはしない方がいいことも多い
• 説明が大変なら、それは悪いアイディアだ
• 説明が簡単なら、それはいいアイディアだろう
• 名前空間はすばらしいアイディアだ
  それよりもすごいことをやろう！

※訳注: おそらくPython作者のGuidoのこと

ABCにおける私の経験はPythonにとても大きな影響を与えたが、ABCグループの設計原理の中には、Pythonのものと根本的に異なるものがいくつか存在する。これらに関しては、Pythonは意図的に違う方向を目指している。

• ABCグループは完璧性を求めて努力していた。例えば、ABCでは、大きいコレクションでの性能を改善するために、ツリーを元にしたデータ構造のアルゴリズムを使っていた。しかし、これは小さなコレクションについては良くなかった。
• ABCグループでは、「大きくて、悪いものがたくさん存在するコンピュータの世界」からユーザをなるべく完璧に隔離しようとしていた。数値の格納できる範囲や、文字列の長さ、コレクションのサイズの限界(メモリの限界を除き)だけでなく、ファイルやディスクを扱って「保存する」といったことや、他のプログラムを扱う必要性からもユーザを遠ざけようとしていた。ABCは必要なモノがすべて手に入る唯一のツールであろうとした。このため、ABCグループではABCに特化した、完全に統合された編集環境を必要とするまでになった。結果的には、ABCの環境から逃げる方法もないことはなかったが、言語から直接アクセスすることはできなかった。
• ABCグループでは、ユーザはコンピュータの経験はまったくない(もしくはそれを忘れようとしている)という想定をしていた。そのため、標準的なプログラミング用語よりも、「新しい人にとって親しみやすい」という別の用語が導入された。例えば、手続きは"手引き(how-tos)"、変数は"場所"とされました。
• ABCグループでは、進化の道筋というのを考慮しないでABCを設計した。言語の設計の過程の中では、ユーザの参加というのは期待されていなかった。ABCはクローズなシステムとして、設計者ができるかぎり完璧なものが作成された。ユーザが「ボンネットの中を調べる」ようなことは推奨されていなかった。プロジェクトの後半には、実装されたプログラムの一部を先進的なユーザ公開しようという話も出てきたが、この話が実現することはなかった。

様々な意味で、Pythonをここまで成功させてきた主な理由の一つが、Pythonを開発するときに私が使用してきたこれらの設計哲学であったと思う。例え完璧を目指さなくても、アーリー・アダプターの人たちの目的を達成するのに、Pythonは「十分に良い」働きをしてきた。ユーザ基盤が成長してくるにつれて、ユーザから出される改善要望が徐々に言語に取り込まれてきた。後のセクションで解説していくが、多くの改良により多くの部分の変更や、言語のコア部分の作り直しが行われた。現在でも、Pythonは改良され続けている。