《Python 编程》（第二版）序言

不到五年前，我为《Python 编程》第一版写了序言。自那时起，这本书的变化与语言和 Python 社区的变化几乎一样大！我不再觉得有必要为 Python 辩护：Mark 的序言中列出的统计数据和发展足以说明一切。

在过去的一年中，Python 取得了长足的进步。我们发布了 Python 2.0，这是一个巨大的进步，它具有新的标准库功能，如 Unicode 和 XML 支持，以及一些新的语法结构，包括增强的赋值：您现在可以写 x += 1 而不是 x = x+1。有些人想知道这有什么大不了的（答案：与其使用 x，不如想象 dict[key] 或 list[index]），但总的来说，这对于那些已经习惯在其他语言中使用增强赋值的用户来说是一个巨大的成功。

不太受欢迎的是扩展的 print 语句：print>>file，它是打印到与标准输出不同的文件对象的快捷方式。就我个人而言，这是我最常用的 Python 2.0 功能，但大多数对此发表意见的人都认为它是一种令人憎恶的东西。新闻组上关于斥责这个简单语言扩展的讨论帖子是有史以来最长的帖子之一——除了永无止境的 Python vs. Perl 的讨论之外。

这引出了下一个话题。（不，不是 Python vs. Perl。在序言中挑起争端不是一个好地方。）我的意思是 Python 进化的速度，这是本书作者非常关心的话题。每当我向 Python 添加一个功能时，Mark 的头发就会多出一撮灰色：又有一个章节过时了！特别是添加到 Python 2.0 的大量新功能，在他编写第二版的时候出现，这让他担心：如果 Python 2.1 添加了许多新的东西怎么办？这本书一旦出版就会过时！

放松，Mark。Python 将继续发展，但我保证我不会删除正在使用的东西！例如，关于 string 模块有很多担忧。现在字符串对象有了方法，string 模块大多是多余的了。我希望我能声明它已过时（或已弃用），以鼓励 Python 程序员开始使用字符串方法。但鉴于大量现有 Python 代码（甚至许多标准库模块）导入了 string 模块，这种更改显然不会在一夜之间发生。删除 string 模块的第一个可能的机会将是在引入 Python 3000 时；即使那时，为了与旧代码一起使用，向后兼容库中可能仍然会有一个 string 模块。

Python 3000？！是的，这是下一代 Python 解释器的昵称。这个名称可以被认为是 Windows 2000 的双关语，或者是指神秘科学剧院 3000，这是一个具有狂热追随者的非常 Python 式的电视节目。Python 3000 何时发布？不会在很长一段时间内——尽管您不必等到 3000 年。

最初，Python 3000 旨在对该语言进行完整的重写和重新设计。这将使我能够进行不兼容的更改，以便修复在向后兼容的方式中无法解决的语言设计问题。然而，目前的计划是将必要的更改逐步引入当前的 Python 2.x 开发线，并提供清晰的过渡路径，包括一段时间的向后兼容性支持。

例如整数除法。与 C 一样，Python 当前将具有两个整数参数的 x/y 定义为具有整数结果。换句话说，1/2 产生 0！虽然大多数顽固的程序员都期望这样，但对于新手来说，这仍然是一个持续的困惑之源，而新手在不断增长的 Python 用户群体中所占的比例越来越大。从数值角度来看，对于 / 运算符，无论操作数的类型如何，都产生相同的值确实更有意义：毕竟，这是所有其他数值运算符所做的。但是我们不能简单地更改 Python，使 1/2 产生 0.5，因为（就像删除 string 模块一样）它会破坏太多现有代码。该怎么办？

该解决方案过于复杂，无法在此处详细描述，它将跨越多个 Python 版本，并且需要逐步增加 Python 程序员的压力（首先通过文档，然后通过弃用警告，最终通过错误）来更改其代码。顺便说一下，用于发出警告的框架将作为 Python 2.1 的一部分引入。抱歉，Mark！

因此，不要期望很快宣布发布 Python 3000。相反，有一天您可能会发现您已经在使用 Python 3000 了——只是它不会被称为 Python 3000，而是类似 Python 2.8.7 之类的东西。您在这本书中学到的大部分内容仍然适用！尽管如此，在过渡时期，对 Python 3000 的引用将比比皆是；要知道这在最纯粹的意义上是有意为之的。与其担心 Python 3000，不如继续使用并学习更多关于您拥有的 Python 版本。

我想谈谈 Python 当前的开发模式。直到 2000 年初，Python 有数百名贡献者，但基本上所有贡献都必须通过我的收件箱。要提出对 Python 的更改，您需要给我发送一个上下文差异，我会将其应用到我的 Python 工作版本中，如果我喜欢它，我会将其签入到我的 CVS 源代码树中。（CVS 是一个源代码版本管理系统，也是几本书的主题。）错误报告遵循相同的路径，只是我也最终不得不提出补丁。显然，随着贡献数量的增加，我的收件箱成为了瓶颈。该怎么办？

幸运的是，Python 并不是唯一有此问题的开源项目，VA Linux 的一些聪明人提出了一个解决方案：SourceForge！这是一个动态网站，提供一整套分布式项目管理工具：一个公共 CVS 存储库、邮件列表（使用 Mailman，一个非常流行的 Python 应用程序！）、讨论论坛、错误和补丁管理器以及下载区域，所有这些都可供任何开源项目按要求使用。

我们目前有一个拥有 30 名志愿者的 SourceForge 签入权限的开发组，以及一个由两倍人数组成的开发邮件列表。有特权的志愿者都已宣誓效忠 BDFL（终身仁慈独裁者——那就是我 :-)。通过一个轻量级的提案和反馈系统——Python 增强提案 (PEP) 来管理主要新功能的引入。我们的 PEP 系统非常成功，以至于当 Tcl 社区从教堂模式过渡到集市模式时几乎逐字复制了它。

因此，我对 Python 的未来充满信心，现在我将舞台交给 Mark Lutz。干得好，Mark。最后用我最喜欢的 Monty Python 引言结束：交给指挥家 Eric！

Guido van Rossum
弗吉尼亚州雷斯顿，2001 年 1 月