龙空技术网

Python的设计理念与简要年谱

ReadingPython 270

前言:

眼前朋友们对“python historyhistory”都比较关注,同学们都想要分析一些“python historyhistory”的相关资讯。那么小编也在网上搜集了一些对于“python historyhistory””的相关知识,希望你们能喜欢,看官们一起来学习一下吧!

本系列文章译自Python之父 Guido van Rossum 的系列博客“The History of Python”。这个博客系列对我们理解Python及其演变很有帮助,在这里翻译推荐给大家,希望大家喜欢,也请大家多多指教!

基本原则

之后的博文将专注于 Python 历史中的一些细节。不过,在此之前,我想先阐述一下我在 Python 的设计和实践中所遵循的一些基本理念。

首先,Python 一开始只是一个个人实验性项目,没有任何官方背景,因此我必须尽快取得成果,某种程度上也是为了争取管理层的支持(这点我倒是做得还不错)。这使我采取了一些节约时间的原则:

借鉴任何有道理的想法。“尽可能简单,而不是相对简单。”(爱因斯坦)只做一件事并把它做好(UNIX哲学)。不必太担心性能——必要时再来优化。跟随潮流,不与大环境作对。别追求完美,往往“足够好”就是完美。(由上一条)有时可以抄近道,尤其在你之后能改正的情况下。

而其它一些原则则不为节约时间,有时还恰恰相反:

Python 不能被某个平台所绑定。有些功能在一些平台上没法用可以接受,但核心功能必须跨平台。机器能处理的,就不能劳烦用户。(正如之后将提到的,事实上我并没有完全遵循这条原则,并因此导致了一些灾难性后果)支持并鼓励用户写出跨平台的代码,但也不拒绝某个平台的特有能力或资源。(这一点与Java形成鲜明对比)一个大型复杂系统,应该在不同层级都支持扩展。从而不论是老手还是新手,都能尽可能地发挥自主性。不能有致命错误。也就是说,只要虚拟机正常工作,用户代码应该在碰到错误后能恢复运行。同时,错误不应该被忽视。(很自然地,本条与上条原则决定了 Python 使用 exceptions 来处理错误)用户代码中的 bug 不允许产生 Python 解释器的未定义行为,不能因用户错误导致内核崩溃。

另外,关于什么是好的编程语言设计,我也有不少想法——主要来自于 ABC 语言团队,也是在这个团队中,我第一次获得了编程语言设计与实践的实际经验(译注:作者在这个团队工作了几年)。不过这些想法很难用文字表达,因为每个人对优雅、简洁与可读性的理解是比较主观的。

虽然之后我也会讨论到 ABC 语言对 Python 的影响,但这里还是要提到一条关于可读性的原则:与日常写作或高等数学相比,Python 中应减少标点符号的使用。我们会使用一些编程语言中的传统符号,比如 “x * y”表示相乘,“a[i]”表示列表切片,或者“x.foo”表示对象属性等,但 Python 不会用“$”表示变量,也不会用“!”表示特殊操作。

Python之禅

Tim Peters,一位忠实的 Python 程序员,后来也成为持续高产的 Python 核心开发者,曾把我未表达的设计原则总结为他所谓的“Python 之禅”,这里我全文引用如下:

美比丑好;

详尽比模糊好;

简单比复杂好;

复杂比繁复好;

扁平比嵌套好;

疏松比密集好;

可读性很重要;

虽然实用比纯粹好,但特例不能破坏原则;

错误不应被忽略,除非有意为之;

如有歧义,拒绝猜测,总有一种——最好是只有一种——没有歧义的解决方案,

虽然这种方案可能一开始并不明显——除非你是 Python 之父;

现在就做比永远不做好,虽然有时,永远不做要比胡做一通好;

如果你的代码难以解释,说明它很烂;

如果你的代码容易理解,则可能是好代码;

命名空间是个好东西——我们得多加应用!

有意避免的观念

虽然我在 ABC 语言的经验对 Python 有很大的影响,但有些地方,它们也采用了完全不同的原则。以下是 Python 有意避免的一些观念:

ABC 语言团队尽力追求完美。比如说,其采用的树状数据结构在处理大型数据集合时效率更高(不过在处理小型数据集合时并不明显)。ABC 语言希望构建一个尽可能独立于外在生态的系统。不仅数字范围、字符串长度、集合规模没有限制(除非超出系统内存),而且用户也不必关心文件、磁盘、“保存”动作或其它应用程序。ABC 语言希望自己能满足用户的所有需求,这也使 ABC 语言团队写了一套完整的,只适用于 ABC 语言的集成编程环境(当然,你要不想用也不是不行,但这一般不是第一选择,而且 ABC 语言不直接支持其它环境)。ABC 语言团队假设所有用户都没有电脑经验(或者愿意抛开之前的经验)。因此,很多术语都用非常“新手”的替代词,比如用“做法(how-tos)”替代“过程(procedures)”,用“地址(locations)”替代“变量(variables)”等。ABC 语言团队在设计时并没有一个预定的演化路径,也不打算让用户参与到语言的设计中来。ABC 语言一开始就是一个封闭的系统,设计者们希望尽可能地把它设计得完美一些,它不鼓励用户关心语言背后的事。虽然有过向高级开发者开放部分源码的讨论,但始终没有实现。

某种意义上说,我在设计 Python 时所采用的设计哲学,或许是其最终取得成功的主要原因之一。它并不在一开始就追求完美,但足够满足大家的需求,随着用户越来越多,许多改进建议被纳入其中。正如大家将在之后的博文中看到的,许多建议都涉及 Python 核心部分的重大改变或重构。直到如今,Python 依然在持续演化之中。

简要年谱

我开发 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

我给 python.org 上还推荐的版本加了链接(译注:现在都是古老的版本了)。有些小版本并不在上面的列表中,比如 2.0.1 等,否则这个列表就太长了。你依然可以在 上找到各版本的源代码。

个人公众号:读书录

标签: #python historyhistory