本系列文章译自Python之父 Guido van Rossum 的系列博客“The History of Python”。这个博客系列对我们理解Python及其演变很有帮助，在这里翻译推荐给大家，希望大家喜欢，也请大家多多指教！
1. 基本原则
之后的博文将专注于 Python 历史中的一些细节。不过，在此之前，我想先阐述一下我在 Python 的设计和实践中所遵循的一些基本理念。
首先，Python 一开始只是一个个人实验性项目，没有任何官方背景，因此我必须尽快取得成果，某种程度上也是为了争取管理层的支持（这点我倒是做得还不错）。这使我采取了一些节约时间的原则：- 借鉴任何有道理的想法。
- “尽可能简单，而不是相对简单。”（爱因斯坦）
- 只做一件事并把它做好（UNIX哲学）。
- 不必太担心性能——必要时再来优化。
- 跟随潮流，不与大环境作对。
- 别追求完美，往往“足够好”就是完美。
- （由上一条）有时可以抄近道，尤其在你之后能改正的情况下。
而其它一些原则则不为节约时间，有时还恰恰相反：- Python 不能被某个平台所绑定。有些功能在一些平台上没法用可以接受，但核心功能必须跨平台。
- 机器能处理的，就不能劳烦用户。（正如之后将提到的，事实上我并没有完全遵循这条原则，并因此导致了一些灾难性后果）
- 支持并鼓励用户写出跨平台的代码，但也不拒绝某个平台的特有能力或资源。（这一点与Java形成鲜明对比）
- 一个大型复杂系统，应该在不同层级都支持扩展。从而不论是老手还是新手，都能尽可能地发挥自主性。
- 不能有致命错误。也就是说，只要虚拟机正常工作，用户代码应该在碰到错误后能恢复运行。
- 同时，错误不应该被忽视。（很自然地，本条与上条原则决定了 Python 使用 exceptions 来处理错误）
- 用户代码中的 bug 不允许产生 Python 解释器的未定义行为，不能因用户错误导致内核崩溃。
另外，关于什么是好的编程语言设计，我也有不少想法——主要来自于 ABC 语言团队，也是在这个团队中，我第一次获得了编程语言设计与实践的实际经验（译注：作者在这个团队工作了几年）。不过这些想法很难用文字表达，因为每个人对优雅、简洁与可读性的理解是比较主观的。
虽然之后我也会讨论到 ABC 语言对 Python 的影响，但这里还是要提到一条关于可读性的原则：与日常写作或高等数学相比，Python 中应减少标点符号的使用。我们会使用一些编程语言中的传统符号，比如 “x * y”表示相乘，“a[i]”表示列表切片，或者“x.foo”表示对象属性等，但 Python 不会用“$”表示变量，也不会用“!”表示特殊操作。
2. Python之禅
Tim Peters，一位忠实的 Python 程序员，后来也成为持续高产的 Python 核心开发者，曾把我未表达的设计原则总结为他所谓的“Python 之禅”，这里我全文引用如下：美比丑好；
详尽比模糊好；
简单比复杂好；
复杂比繁复好；
扁平比嵌套好；
疏松比密集好；
可读性很重要；
虽然实用比纯粹好，但特例不能破坏原则；
错误不应被忽略，除非有意为之；
如有歧义，拒绝猜测，总有一种——最好是只有一种——没有歧义的解决方案，
虽然这种方案可能一开始并不明显——除非你是 Python 之父；
现在就做比永远不做好，虽然有时，永远不做要比胡做一通好；
如果你的代码难以解释，说明它很烂；
如果你的代码容易理解，则可能是好代码；
命名空间是个好东西——我们得多加应用！
3. 有意避免的观念
虽然我在 ABC 语言的经验对 Python 有很大的影响，但有些地方，它们也采用了完全不同的原则。以下是 Python 有意避免的一些观念：ABC 语言团队尽力追求完美。比如说，其采用的树状数据结构在处理大型数据集合时效率更高（不过在处理小型数据集合时并不明显）。
ABC 语言希望构建一个尽可能独立于外在生态的系统。不仅数字范围、字符串长度、集合规模没有限制（除非超出系统内存），而且用户也不必关心文件、磁盘、“保存”动作或其它应用程序。ABC 语言希望自己能满足用户的所有需求，这也使 ABC 语言团队写了一套完整的，只适用于 ABC 语言的集成编程环境（当然，你要不想用也不是不行，但这一般不是第一选择，而且 ABC 语言不直接支持其它环境）。
ABC 语言团队假设所有用户都没有电脑经验（或者愿意抛开之前的经验）。因此，很多术语都用非常“新手”的替代词，比如用“做法（how-tos）”替代“过程（procedures）”，用“地址（locations）”替代“变量（variables）”等。
ABC 语言团队在设计时并没有一个预定的演化路径，也不打算让用户参与到语言的设计中来。ABC 语言一开始就是一个封闭的系统，设计者们希望尽可能地把它设计得完美一些，它不鼓励用户关心语言背后的事。虽然有过向高级开发者开放部分源码的讨论，但始终没有实现。
某种意义上说，我在设计 Python 时所采用的设计哲学，或许是其最终取得成功的主要原因之一。它并不在一开始就追求完美，但足够满足大家的需求，随着用户越来越多，许多改进建议被纳入其中。正如大家将在之后的博文中看到的，许多建议都涉及 Python 核心部分的重大改变或重构。直到如今，Python 依然在持续演化之中。
4. 简要年谱
我开发 Python 的时候，也正是其它动态（而且开源）编程语言开始活跃，并越来越受欢迎的时代，比如 Tcl、Perl、以及（后来的）Ruby。为把 Python 置于一种历史视角之下，我将 Python 的版本发布记录罗列如下，因为我也没记录当时的所有事情，所以早期的时间比较宽泛：发布日期 版本号
- 1989.12 开始开发
- 1990 在 CWI 发布内部版本
- 1991.02.20 0.9.0（发布在 alt.sources）
- 1991.02 0.9.1
- 1991.08 0.9.2
- 1991.12.24 0.9.4
- 1992.01.02 0.9.5（只支持苹果系统）
- 1992.04.06 0.9.6
- 1992年某天 0.9.7beta
- 1993.01.09 0.9.8
- 1993.07.29 0.9.9
- 1994.01.26 1.0.0
- 1994.02.15 1.0.2
- 1994.05.04 1.0.3
- 1994.07.14 1.0.4
- 1994.10.11 1.1
- 1994.11.10 1.1.1
- 1995.04.13 1.2
- 1995.10.13 1.3
- 1996.10.25 1.4
- 1998.01.03 1.5
- 1998.10.31 1.5.1
- 1999.04.13 1.5.2
- 2000.09.05 1.6
- 2000.10.16 2.0
- 2001.02.25 1.6.1
- 2001.04.17 2.1
- 2001.12.21 2.2
- 2003.07.29 2.3
- 2004.11.30 2.4
- 2006.09.16 2.5
- 2008.10.01 2.6
- 2008.12.03 3.0
我给 http://python.org 上还推荐的版本加了链接（译注：现在都是古老的版本了）。有些小版本并不在上面的列表中，比如 2.0.1 等，否则这个列表就太长了。你依然可以在 http://www.python.org/ftp/python/src/ 上找到各版本的源代码。
个人公众号：读书录
2859
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
