これは、お気に入りの言語の著者の公式ブログの記事の最初の部分です。 したがって、ナレーションはグイド・ファン・ロッサム自身に代わって行われます。 第二部はこちらです。
さらにテキストを読むと、Python言語の歴史をさらに深く掘り下げることができます。 ただし、これを行う前に、Pythonの設計と構造の開発中に意思決定を行うのに役立つ哲学的なことに焦点を当てたいと思います。
まず、Pythonは当初、インディープロジェクトとして位置づけられ、1人だけが従事していました-公式予算はありませんでしたが、できるだけ早く成果を達成したかったので、特に重要なステップは、プロジェクトをサポートするよう経営陣に説得することでしたかなり成功しました）。 これは、貴重な時間を節約する一連のルールにつながりました。
「理にかなっているどこからでもアイデアを借りる。」
「物事は可能な限りシンプルであるべきですが、シンプルではありません。」（アインシュタイン）
-ひとつだけやれば、うまくいく（「UNIX Philosophy」）。
-パフォーマンスについて気にしないでください-必要に応じて、将来的に最適化することが可能になります。
-鉄と戦うのではなく、ただ流れてください。
-完璧を達成しようとしないでください。多くの場合、「十分」がまさにあなたが必要とするものです。
-（この方法で）特に後でこの問題を解決できる場合は、角を切ることがあります。
残りの原則は、時間に関してそれほど経済的ではありませんでした。 時には逆の効果さえありました：
-Pythonフレームワークはプラットフォーム固有である必要はありません。 機能の一部が利用できない場合もありますが、基盤はいつでもどこでも動作するはずです。
-マシンが独自に解決できる詳細をユーザーにロードしないでください（このルールに常に従ったわけではありません。これによる壊滅的な結果については後で説明します）。
-プラットフォームに依存しないコードのサポートとプロモーション。ただし、特定のプラットフォーム機能へのアクセスを遮断しないでください（ちなみに、これはJavaとは対照的です）。
-大規模で複雑なシステムには、マルチレベルの拡張性が必要です。 これにより、ユーザーがどんなに混乱しているように聞こえても、自分自身を助ける能力が向上します。
-間違いは致命的ではありません。 つまり、ユーザーコードは、仮想マシンがまだ機能している間、すべてを生き残ることができる必要があります。
-同時に、エラーが気付かれることはありません（最後の2つのことから、構造化中に例外を使用することになりました）。
-ユーザーコードのエラーには、Pythonインタープリターが誤動作する可能性があります。 カーネルクラッシュがユーザーエラーになることはありません。
したがって、プログラミング言語の優れたデザインを作成するための多くのアイデアがあり、それらは言語の実装と構造化の最初の経験を得たABCグループでの作業中に私に大きな影響を与えました。 これらのアイデアは、主に優雅さ、シンプルさ、読みやすさなどの主観的なものを中心に展開するため、言葉で説明するのは困難です。
Python開発に対するABCの経験の影響については少し後で説明しますが、コードの読みやすさに関する1つのルールに言及したいと思います。句読点は、書かれた英語または高校の代数での通常の使用に従って、「保守的に」使用する必要があります 例外は、乗算用の「x * y」、配列要素へのアクセス用の「a [i]」、または「x.foo」属性選択など、プログラミング言語の伝統となったもののみに関係しますが、Pythonはどちらも使用しません「$」は変数を示し、「！」は演算の否定を示します。
長い間忠実なPythonユーザーであり、その後彼の最も多才で粘り強い開発者になったTim Petersは、私の構造の異なる原則をZen Zenと呼ばれるものに結合しようとしました。 私はそれを完全にここに持ってきます：
-美しさはさよりも優れています。
「透明度は不明瞭さよりも優れています。」
-単純さは複雑さよりも優れています。
-複雑さは混乱よりも優れています。
-プレーンはネストよりも優れています。
-離婚は集中力よりも優れています。
-可読性が高く評価されています。
-特別なケースは、それらのルールに違反するほど特別ではありません。
-実用性は清thanさよりも高いですが。
-エラーに気付かないことはありません。
-エラーが非表示でない場合。
-不確実性に直面した場合、推測の試みを放棄することをお勧めします。
「1つあるべきです。問題を解決する明白な方法が1つだけであれば理想的です。」
-この方法は一見したところ明らかではないかもしれませんが、特にオランダ人の場合はそうかもしれません。
「今では、これまで以上に優れています。」
「多くの場合、今よりも良くなることはありません。」
-構造の説明が簡単でない場合、これは悪い考えです。
「構造を単純に説明する場合、それは良い考えかもしれません。」
「名前空間は本当に良いアイデアです。名前空間を大きくしましょう！」
ABCでの私の経験はPythonに大きな影響を与えましたが、ABCグループには、Pythonのものとは根本的に異なる独自の構造化原則がありました。 多くの点で、Pythonは意図的に真剣にそれらから離れました：
-ABCグループは卓越性のために努力しました。 たとえば、彼らはツリー状のデータ構造を使用したアルゴリズムを使用しました（漸近的に最適ですが、小容量の場合はそれほど高速ではありません）。
-ABCグループは、可能な限りユーザーを「コンピューターの大きな悪の世界」から分離したいと考えていました。 数値のサイズ、行の長さ、またはデータセットのサイズに制限がないこと（もちろん、使用可能なメモリの合計の範囲内）だけでなく、ユーザーはファイル、ディスク、「保存」または他のプログラムをいじる必要もありません。 ABCは彼らが必要とする唯一のものであるべきです。 この仮定により、ABCグループはABCに固有の完全な統合環境編集ツールを作成するようになりました（もちろん、ABC環境から「抜け出す」ことは可能ですが、これは二次的なものであり、言語自体の観点からは考慮されませんでした）。
-ABCグループは、ユーザーがコンピューターエクスペリエンスを必要としない（または失うことを望んだ（:)-およその翻訳者）と考えていました。 したがって、彼らが信じた代替用語は、他のプログラミング言語よりも「初心者に優しい」構造につながると考えられていました。 たとえば、プロシージャは「ハウツー」と呼ばれ、変数は「パス」と呼ばれました。
-ABCグループは、特別な開発計画やユーザーサポートをあまり期待せずにABCを構築しました。 ABCは、開発者自身がABCをそのように考えているほど完璧な、閉じたシステムとして作成されました。 ユーザーが「カバーの下を見る」試みは奨励されませんでした。 「上級ユーザー向け」のシステム構造の特別なセクションの開設についての話がありましたが、これは将来実装されませんでした。
いずれにせよ、私がPythonを開発するときに使用した構造化哲学は、率直に言って顕著な成功の理由の1つとして明らかに役立ちました。 最初のフォロワーは、「卓越性を追求する」のではなく、通常の問題を解決するのに「十分に」機能することを発見しました。 ユーザーベースの増加とともに、改善の提案が言語に含まれました。 後の出版物で見るように、これらの改善の多くは、かなり深刻な変更と言語のルートの改訂を伴いました。 現在でも、Pythonは進化し続けています。
（c）グイドヴァンロッサム