Python 是一种非常流行的、高级编程语言，在 2008 年 Linux Journal 读者选择奖中被评为最受欢迎的脚本语言。在本次访谈中，Python 的创造者 Guido van Rossum 分享了他对革命性的新 Python 3000 的见解，为什么向后不兼容的痛苦是值得的，他对 Python 2.6 分支的展望，以及他最近在 Google 的工作。

Guido van Rossum

JG： 当读者看到这次访谈时，Python 3000（又名 Py3K 和 Python 3.0）应该已经发布了。新版本中有哪些会让开发者兴奋的功能？

GVR：您可能听说过 Python 3000 将引入向后不兼容的更改。单单这一点可能就足以让开发者兴奋，或者至少感到不安。所以，首先让我强调一下，总的来说，Python 3.0 仍然是您之前喜爱和使用的语言，只是做了一些清理。您可能想将此与 Perl 6 与 Perl 4 进行对比，Perl 6 是一种全新的语言，具有完全不同的实现。我们所做的任何事情都没有那么剧烈！

许多清理工作都相当良性。例如，我们最终摆脱了字符串异常（所有异常都必须定义为类）。有很多像这样的清理工作，我建议读者访问 python.org 网站查看（大部分）枯燥的细节。

一些更改 看起来 具有争议性，但实际上是一大进步，例如用 print() 函数替换 print 语句。将其设为函数的最大优点是我们可以使用熟悉的 keyword=value 语法来指定行为变化，例如打印到不同的文件或抑制最终的换行符。我们也可以更轻松地添加新的关键字。例如，在 Py3k 中，您可以覆盖项目之间的分隔符，与基于语句的语法的演变相比，这使得未来的演变更容易。使用标准函数语法也使得用您自己设计的函数替换内置的 print 函数变得容易得多。这是程序生命周期中的常见转换。最初作为简单的 print 语句开始的东西，在某个时候必须变成日志调用，或者至少可以重定向到不同的文件，并且所有这些更改都更容易通过函数调用一致地进行。

有一组更改（相对而言）是革命性的，同时，它可能是造成最大转换痛苦的原因，而且 也可能带来最大的解脱。我们正在对 Unicode 采取根本不同的态度。一点历史：Python 1 仅支持八位字符串，它们既用于文本数据，也用于二进制数据。Python 2 保留了八位字符串的这种双重用途，但添加了 Unicode 字符串。这样做是为了保持与 Python 1 的向后兼容性，但这产生了一个新的主要歧义。有两种表示文本字符串的方式，要么是八位字符串，要么是 Unicode 字符串。此外，八位字符串的含义仍然模棱两可，因为它们既用于文本，也用于二进制数据。

在 Python 3 中，我们打破了兼容性，并以不同的方式划清界限。将有一种 bytes 类型用于二进制数据（和 编码后的 文本，如 UTF-8 或 UTF-16），并且将有一种 str 类型仅用于文本，并且能够表示所有 Unicode 字符。bytes 类型的实现与旧的八位字符串类型非常相似，而 str 类型的实现是从旧的 Unicode 类型复制而来的。与 Python 2 相比，最大的改进是消除了我上面提到的两个歧义。现在，用法（数据或文本）和类型（bytes 或 str）之间存在 1:1 的映射。早期采用者的报告表明，开发人员非常欣赏这种变化，并且乐于为此付出代价。一些第三方项目，例如 Django，已经在 Python 2 中采用了一个本质上相同的约定。所有文本都存储在 Unicode 字符串中，八位字符串仅存储二进制数据，但 Python 2 不会帮助强制执行这一点。

还有一些其他与 Unicode 相关的更改。默认源编码现在是 UTF-8，标识符可以包含非 ASCII 字母，并且 repr() 函数将不再将所有非 ASCII 字符转换为十六进制转义符（当然，它仍然会转义控制字符）。

JG： 回顾过去，您是否后悔最终版本中通过的任何更改？

GVR：不，我对结果非常满意。我认为我们在改变太多和改变太少之间取得了惊人的平衡。在 Py3k 开发的后期，我们切换到基于时间的发布计划，这真的很有帮助，因此我们有了一种明确的方式来阻止永无止境的语言改进提案流。

JG： Python 3000 目前比 2.5 慢。一旦认真调优，它会像 2.5 一样快还是更快？

GVR：我预计到 3.0 发布时，我们将接近 2.5 的速度。我们可能会在之后继续调优它，如果过去的经验可以衡量未来的性能，我们会看到随着新版本的发布，速度会持续提高。

JG： Python 3 打破了与 2.6 版本的向后兼容性。对于一种编程语言，尤其是对于像 Python 这样拥有庞大用户群的语言来说，这是一个相当大胆的举动。我记得的唯一一次有人尝试这样做是微软从 VB6 升级到 VB.NET，这一举动让许多 VB6 程序员在六年后的今天仍然感到不满。您是否对这一举动感到担忧？

GVR：我认为您可能忘记了 Perl 6。

我的理解是，VB.NET 实际上与 VB6 根本不同，比 Python 3 与 Python 2 的不同要大得多。Python 3 中的大多数差异都相对接近表面。特别是，我们有意识地选择 不 从根本上改变底层实现。如果我理解正确，VB.NET 使用了与 VB6 完全不同的虚拟机（基于新的 .NET 技术）。Python 3 情况并非如此。我们从 Python 2 VM 的一个分支开始 Py3k，并逐步修改它以支持新语言。但是，大多数实现细节完全相同，直到今天，我们仍然例行地将主干（将作为 Python 2.6 发布）中的更改合并到 Py3k 分支中。

我当然不想低估开发人员从 Python 2 过渡到 Py3k 的成本。我们至少在两年前就开始考虑这种过渡，并且我们制定了几项并行策略，以使开发人员能够舒适地进行更改。

首先，Python 2 将在很长一段时间内与 Python 3 并行得到充分支持。我个人的预期是，至少在三到五年内，开发人员可以完全自由地在 Python 2 或 Python 3 之间进行选择，并获得相同的支持级别。将会有新的 Python 2 版本发布，从 2.6 开始，与 Python 3 版本并行。

其次，我们设计了一个特定的双管齐下的过渡策略。该策略的第一个方面是与 3.0 版本同时发布 Python 2.6。2.6 将向后兼容 2.5，但它还将包含一组 可选的 警告，提醒您程序中存在的各种问题，这些问题在您将程序移植到 Py3k 时会中断。这些警告仅在通过命令行选项专门请求时才会发出，因此它们不会成为从 2.4 或 2.5 升级到 2.6 的障碍，无论您是否计划将代码移植到 3.0。此外，2.6 还将包含一些向后移植的 3.0 功能，我们希望这将鼓励人们开始以一种方式使用 2.6，从而减少他们在准备好使用 3.0 时的痛苦。

过渡策略的第二个方面是一个源代码转换工具，我们称之为 2to3。此工具处理将 Python 2 代码转换为 Py3k 时遇到的大多数小的语法更改。例如，它自动将 print 语句转换为 print() 函数调用，将 Unicode 字面量（例如u"..."）转换为常规字符串字面量，从长整数字面量中删除尾随的 L，等等。它还在将对流行的字典方法（如 .keys() 和 .iterkeys()）的调用转换为它们的 Py3k 等效项方面做得不错（尽管不完美）。

这两个方面相辅相成。2to3 工具处理语法更改，而 Python 2.6 中的 Py3k 警告处理那些纯粹的语法工具无法轻松处理的更改。由于 Python 是一种如此动态的语言，因此通常无法自动进行需要有关变量或属性类型的信息的转换。2to3 工具会保留这些，但是 2.6 和 3.0 语言之间有足够的重叠，以至于通常可以更改源代码，使其仍然与 Python 2.6（通常也与旧版本）兼容，不产生 Py3k 警告，并且可以使用 2to3 工具安全地转换为有效的 Python 3.0 源代码。

JG： 此外，您认为升级到 Python 3000 的过程有多复杂？

GVR：我认为我在上一个问题的回答中已经对复杂性给出了一个不错的指示。转换的一般工作流程可能如下

在版本控制方面，您很可能将长期维护代码的两个分支：2.6 版本和 3.0 版本。对 2.6 版本的更改应使用 2to3 工具合并到 3.0 版本。

JG： 到目前为止，您从 Python 3000 的早期采用者那里得到了什么样的反馈？

GVR：我们听到了从纯粹的兴奋到极度恐惧的各种声音。考虑到变化的幅度，我们不能期望每个人都高兴，但总体趋势是谨慎乐观的。正如预期的那样，大多数开发人员对大多数新功能感到满意。虽然几乎每个人都有一两个自己的不满，但这些似乎大多是异常值，并且没有任何更改被许多人认为是不需要的。

JG： 是否有任何大型项目已经转换为 Python 3000，结果如何？

GVR：现在说还为时过早。我们才刚刚发布 2.6 和 3.0 的第一个 beta 版本，到目前为止，第三方开发人员，尤其是大型软件包的开发人员，重点是 2.6 而不是 3.0。

JG： 是否有可能出现 2.x 系列的 rogue 分支，这会困扰您吗？

GVR：我不希望发生任何“rogue”分支。Python 社区倾向于在长期内偏爱共识而不是冲突。

JG： 升级过程中接受或拒绝更改的过程是怎样的？

GVR：我们首先在 PEP 3000 中为升级设置了一些基本参数：主要目标是修复早期的设计错误，并清理两种做事方式从改进语言的愿望中演变出来的情况，同时保持向后兼容性（例如，新式类与经典类）。这是一个强有力的论据，可以将许多更激进的更改提案拒之门外。

剩下的就是长时间的社区讨论，如果共识仍然难以捉摸，则由我本人偶尔进行打破僵局。我有一套非常微妙的直觉，用于判断任何一个问题的最“Pythonic”解决方案，在实用主义和原则之间保持着微妙的平衡。但是，我尝试仅在充分讨论澄清了拟议变更的动机和用例之后才使用它。

JG： 是否有您想要的更改被拒绝，或者是否有您不想要的更改被接受？

GVR：这很难说。我当然提出过被拒绝的事情，但最终，我总是同意拒绝——反之亦然。

JG： 您目前对 Python 4000 及更高版本的想法是什么？

GVR：我希望到那时我已经退休了！

JG： 我们的荣誉退休出版人，也是您的老朋友 Phil Hughes 让我问您，“Django [高级 Python Web 框架] 真的像它看起来那么酷吗？”

GVR：哦，是的，它很酷。（嗨，Phil！）我喜欢它，因为它在理论和实践之间取得了非常 Pythonic 的平衡，并且因为项目的组织与 Python 本身非常相似。Django 开发人员运行着一个出色的开源项目，认真听取用户和贡献者的意见，而不会被“功能主义”分散注意力。

JG： KDE 4.x 放弃了经典桌面，转而使用 Plasma，后者支持使用多种编程语言编写脚本化的插件或小程序。您认为 Python 在这个领域中扮演什么角色？

GVR：这是我第一次听说这件事，所以我宁愿不做任何草率的评论。我希望如果 Plasma 变得流行，其开发人员会使其可以使用 Python 进行脚本编写。

JG： 最近您在 Python 社区的发展中看到了哪些有趣的趋势？

GVR：我很高兴在过去一年左右的时间里涌入了新的开发人员。这确实用新的想法和新的专业知识领域丰富了社区，并减轻了一些多年来一直保持事物运转的老手的压力。

另一个完全不相关，但也非常令人兴奋的趋势是 PyPy 项目的活动。您可能还记得，PyPy 最初是尝试用 Python 编写一个可移植的 Python 解释器，通过使用特定于 Python 的 JIT 使其快速。大多数 PyPy 开发人员都在欧洲，在欧盟（欧洲联盟）两年的资助下，该项目取得了巨大的进展。正如事先约定的那样，欧盟的资助在两年后结束了，但最近 Google 开始资助一些特定的 PyPy 活动，我很高兴这些最终将使 PyPy 成为 CPython 的可行替代方案。

JG： 您已经在 Google 工作了将近三年。您能透露一下他们让您从事什么工作吗，还是这是最高机密？此外，Python 是否受 Google 的 80/20 规则的约束——该规则允许员工将 20% 的时间用于对业务可能具有价值的个人项目——还是您有不同的安排？

GVR：我的第一个 Google 项目是 Mondrian，这是一个用于使用 Perforce 进行协作代码审查的内部 Web 工具，这已经不是什么秘密了。自去年 11 月以来，我一直在从事 Google App Engine 的工作，这是一个令人兴奋的项目，它允许 Web 开发人员在 Google 强大的基础设施上运行可扩展的 Python Web 应用程序。（将来，也将支持其他语言。）

我已经编写了一个 App Engine 演示，它重用了 Mondrian 的一些组件，并将它们重构为一个用于 Subversion 的代码审查工具。经过 Google 的许可，我已将其作为开源发布。您可以在 codereview.appspot.com 上看到它的运行情况，您也可以在那里找到指向源代码的链接。

我没有严格意义上的 20% 项目，但我已获得 Google 的同意，我可以将 50% 的时间用于 Python，没有任何附加条件，所以我称之为我的“50% 项目”。

JG： 非常感谢您的见解，Guido，祝您新的 Python 一切顺利！