《Python编程》(第2版) 前言

不到五年前，我为《Python编程》的第一版写了前言。从那时起，这本书的改变之大，几乎与Python语言和社区的变化不相上下！我不再需要为Python辩护：Mark在序言中列出的统计数据和发展情况不言自明。

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

对扩展 `print` 语句的热情就没有那么高了：`print >> file`，这是一个打印到不同于标准输出的文件对象的快捷方式。就我个人而言，这是我使用最频繁的Python 2.0特性，但大多数对此发表看法的人都认为它是一个令人憎恶的东西。新闻组上关于这个简单语言扩展的激烈讨论是史上最长的讨论之一——除了永无止境的Python与Perl之争。

这让我想到了下一个话题。(不，不是Python与Perl。与其在前言中挑起争端，不如去别处。) 我指的是Python进化的速度，这是本书作者心头的一个话题。每当我给Python添加一个新特性，Mark的头发就会多一根白发：又有一个章节过时了！特别是Python 2.0中新增的大量特性，恰好在他编写第二版时出现，让他担心：如果Python 2.1也添加这么多新东西怎么办？那这本书一出版就过时了！

放轻松，Mark。Python会继续发展，但我保证我不会删除仍在积极使用的东西！例如，很多人担心 `string` 模块。现在 `string` 对象有了方法，`string` 模块在很大程度上是多余的。我希望我能宣布它过时（或弃用），以鼓励Python程序员转而使用字符串方法。但考虑到现有的大部分Python代码——甚至许多标准库模块——都导入了 `string` 模块，这种改变显然不会一蹴而就。移除 `string` 模块的第一次可能的机会将是在Python 3000的引入时；即便如此，可能在向后兼容库中仍然会有一个 `string` 模块供旧代码使用。

Python 3000？！是的，那是下一代Python解释器的昵称。这个名字可以被认为是Windows 2000的谐音，或者是对《神秘科学剧场3000》的引用，那是一个拥有狂热追随者的、恰如其分的Pythonesque电视节目。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 2.8.7之类的。而且你在这本书中学到的大部分内容仍然适用！尽管如此，与此同时，对Python 3000的引用会随处可见；你只需要知道这在最纯粹的意义上是故意的“概念产品”（vaporware）。与其担心Python 3000，不如继续使用和学习你拥有的Python版本。

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

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

我们目前有一个开发小组，拥有SourceForge的签入权限，由30名志愿者组成，还有一个开发邮件列表，人数是前者的两倍。这些享有特权的志愿者都已宣誓效忠BDFL（终身仁慈独裁者——那就是我 :-）。新主要特性的引入通过一个轻量级的提案和反馈系统进行管理，即Python增强提案（PEP）。我们的PEP系统非常成功，以至于当Tcl社区进行类似的从“大教堂”到“集市”的转变时，他们几乎照搬了我们的系统。

因此，我怀着对Python未来的信心，将发言权交给Mark Lutz。干得好，Mark。最后用我最喜欢的Monty Python名言来结束：埃里克，乐队指挥，你来接手！

吉多·范罗苏姆
雷斯顿，弗吉尼亚州，2001年1月