从LinuxToy上看到了Python的作者开blog写史的消息，马上进去看看，发现现在一共有两篇文章。因此想到现在做一个粗略的翻译可能会对中文读者有帮助，就抽了点时间翻译了其中的第二篇文章。我翻译的很不正规、也很不严谨。但对于不想做Python历史学家的普通读者应该能看通大略意思。
This post is for translating an article named “Python’s Design Philosophy” by Guido van Rossum.
原文地址：http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html
后面的blog文章会讨论Python历史的（血淋淋的）细节。然而在那之前，我想详细的说一下在我设计和实现Python时帮助我做出决定的哲学上的指导方针。
首先，Python最初是被构思成一个个人的“实验”项目──没有官方预算，我希望能很快得到结果，以便说服我的老板支持这个项目（我做的相当成功）。这样产生了一些节省时间的规则：
- 从任何可以的地方借鉴思想。
- “任务应当尽可能简单的完成。”（爱因斯坦）
- 做好一件事（“UNIX哲学”）。
- 别过于担心效率──在最后需要的时候再优化。
- 不要随大流。
- 不要试图做到最好因为“足够好”就足够了。
- （因此）抄近路是可行的，特别是当你可以在将来再完善。
其它的原则不是为了节省时间。有时它们反而是恰恰相反的。
- Python的实现不应当限制在一个平台上。部分功能可以不跨平台，但核心一定要可以随处工作。
- 不要用机器可以处理的细节去打扰用户（我不总是遵守这点，后面的章节会讲一些惨痛的后果）。
- 支持、鼓励平台无关的用户代码，但不要切断访问平台特性的功能（这点与Java完全不同）。
- 一个大型的复杂的系统应当有不同层次的扩展性。这点最大化了用户的机会，或多或少的帮助了他们。
- 错误不应当是致命的。这样，在虚拟机还正常工作的时候，用户的代码可以从错误中恢复。
- 同时，错误应该给出提示。（这两点让我决定在实现中使用异常）
- 用户代码中的bug不应当导致Python解释器的异常行为。也就是说，解释器的崩溃与用户无关。
最终，我对好的编程语言的实现有了一些想法。多数是我在我的第一次语言实现与设计经验──ABC小组中获得的。这些想法很难用语言表达，因为他们多数是我对一些像优雅、简单、可读性之类概念的主管思考。
尽管我会讨论更多的ABC给Python的影响，我想先单独提出一条可读性的规则：应当保守的使用标点符号，就像在书面英语和高中代数一样。个别在编程语言中长期使用的符号是例外，比如“x*y”表示乘法，“a[i]”表示数组元素，或者“x.foo”表示属性。但Python不使用“$”来表示变量，或用“!”来表示带有副作用的操作。
Tim Peters是一位Python的长期用户并在最终成为了多产坚定的开发者。他在《Python之禅》一文中总结了我的一些未公开的设计原则。我全部引用在这儿：
- 漂亮比丑陋要好。
- 直接比含蓄要好。
- 简单比繁复要好。
- 繁复比复杂要好。
- 平铺比嵌套要好。
- 稀疏比密集要好。
- 可读性很重要。
- 特例不能破坏规则。
- 尽管实用优于纯正。
- 错误永远不能安静的通过。
- 除非明确的让它安静。
- 拒绝在模糊的地方猜测。
- 应当有一种，并且最好只有一种，明显的方法去做一件事。
- 尽管开始时那种方法并不明显，除非你是荷兰人。
- 现在要比永远不更好。
- 尽管永远不常常比当前要好。
- 如果一个实现很难解释，那么它就是一个不好的想法。
- 如果一个实现容易解释，那么它可能是一个好的想法。
- 名称空间是一个很伟大的想法，让我们做的更多。
尽管我在ABC的经验很大的影响了Python，ABC小组也有几条Python完全排斥的设计原则。许多时候，Python有意识的防止这样做：
- ABC小组努力的做到完美。例如，他们使用被证明为对处理大型数据有很高效率的基于树的数据结构算法（但对小型数据却不那么好）。
- ABC小组希望尽量完全的从“巨大、不好的计算机世界”中隔离用户。在那里，不仅数字没有限定的范围，字符串没有限定的长度，集合没有限定的体积（在可用内存之外），而且用户也不应该处理文件、磁盘、“存储”或其它程序。ABC应当是用户需要的唯一工具。这点也让ABC小组创建了一个仅仅用于ABC的完全集成的编辑环境（当然有从ABC环境中逃离的方法，但它们通常是些事后的观点，而不是直接通过语言本身来达到的）。
- ABC小组假定用户没有之前的计算机使用经验（或者他们希望用户忘记那些经验）。因此他们引入了一些新的“对初学者友好的”术语，而不是使用标准的编程语言的术语。例如，子程序被称为“how-tos”，变量被称为“locations”。
- ABC小组没有按照头脑进化的路线来设计ABC，也没有期待用户参与到语言的设计中来。ABC被设计成一个封闭的系统，以设计者的最大努力把它做到完美。用户不被鼓励去“看看盖子下面”。尽管在项目的后期有关于对高级用户开放部分实现的讨论，但永远没有实现。
从许多角度上来说，我在创建Python的时候用的设计思想大概是它获得巨大成功的主要原因。没有努力去做到完美，早期的使用者们发现Python工作的“足够好”的满足了他们的需求。通过用户的增多，对语言的改进建议被逐渐的吸收进来。就像我们将要在以后的章节中见到的那样，许多这些改进导致了重大的改进和语言核心部分的重构。哪怕是今天，Python也在继续演化中。
“简单比繁复要好”—说得好