Python 之父谈 Python 已翻译 100%

在宣传海报上，Python 之父 Guido van Rossum 在 EuroPython 2015 会议的发言分为讲话稿和现场问答部分，但是他上台后将全程改为现场问答的形式。他在回答现场观众的问题前，首先以自己的几个问题和答案推动了会议的进程。话题包括 Python 3（以及3.5），为何没有2.8版本，为什么有这么多开放的bug，Pypy，还有他讨厌 Python 的哪些部分。

Django Girls

Van Rossum 自己的第一个问题是他如何看待 Django Girls ——前一天演讲的主题。他说，这是一次伟大的对话，他热爱讲故事。他的讲话中将不会有相关的内容，或者任何“漂亮的幻灯片”。当他听到Ola...或Ola...为这些幻灯片画了松鼠和獾时，他非常震惊。

他喜欢的另一个方面是他们申明他们不知道他们正在做什么。让他想起了 25 年前开始写 python，他也不知道接下来该怎么做，例如，他不知道一门编程语言需要不同角色的社区。

他也被他们一年时间创造的“强势品牌”所感染，“我预计 Ola and Ola、Django Girls 将走的很远。”

Python 版本

转换方向，他的下一个疑惑是为什么开发者转向 python 3。“你为什么不能放弃 python 3？”，他设问自己。但他没有说人们应该转移向 python 3，但他也不想他们这样做，但是确实有许多困难的工作需要花费一些其他的东西。例如这些应用和网站的面貌，python 2.7 现在并没有死去，而且会有更多安全修复，或许，接下来的五年将会有更加安全的面貌。移植到 python 3 将有许多繁杂的工作，所以为什么要打扰?

一方面，Python 3是一种要比 Python 2“好得多的语言”。这是一种非常容易教的语言。比如，Django Girls 工作室是完全基于 Python 3 进行开发的。要说 Django 的开发者没有做过基于框架接口的垃圾工作，那从来都是不可能的。这样一来，使用这种语言（和这种框架）使得第一次开发体验更加让人愉快。

随 着时间推移，Python 将变得越来越好。比方，Python 3.5 中有“很多出色的新的东西”。他说，Python 2 是一种优秀的语言并将一如既往地保持着原本的特性，这让它渐渐地向完美的2.7版靠近。要想在核心开发者所做的所有工作中获得益处，唯一办法是转移到 Python 3 中去。

一个长期存在的问题是，为什么没有让 Python 2.8 发布，尽管 Van Rossum 指出，可能有些风格有些过时的问题。 Python 2.8 不能解决任何人们想要解决的问题。没有新的特性，这意味着没有理由让版本升级，而从 Python 3 开始移植的闸门已经打开。那将使得程序既需要移植到 2.8，还需要移植到 3。

Unicode 是一个移植到 3 的大障碍。但是“该适可而止了”。因此 Python 2 正处在一个状态中，它没有得到新的特性。这让核心的开发者把精力集中在 Python 3 上，把它做得更好。

他接下来谈及了即将在 9 月份完成的 Python3.5。他曾经对如此至多的特性无法选择，举个例子来说，  os.scandir() 带来的性能优化非常的棒，但实际上大部分的用户并不会注意到。另一部分用户对新的矩阵乘法运算符将会感到非常开心。像 NumPy 和其他的科学计算包将会开始使用这玩意，这个特性将会比调用一个函数来的『自然』多了。

或许他最喜欢的 Python3.5 特性是语法提示 , 也就是他自己做的那个 PEP。为了让 PEP 接受它，他可下了不少功夫，自己做为自己的裁判，说服自己接受自己的工作，这也有点小奇怪。不过他还是希望还是有人来给帮他做一个独立的 Code Review，就像 Mark Shannon 曾经作为 BDFL 代表做过的事情一样，他说。

“如果你对这个也不感到意外的话，上一个 PEP 接受的 Python3.5 特性就是他作为兴趣研究搞的异步与等待关键词。这个将会提供一个更自然的途径去写关于协程的代码。”

公开的bug

最近有人问及他关于 python bug 跟踪里所有公开 bug 的问题。如果你随便找一个公开的 bug 看，你会发现这个 bug 可能已经打上了补丁，还有一长串的讨论，甚至核心的开发人员也说补丁可以合并进主干了，但是其实 bug 并没有修复。难道这是一个不靠谱的核心开发者或者是老好人？那还需要这些补丁做些什么？

他说，这些问题同样也在一些其他大的工程上存在。诸多 bug 没有通过正确的方式关闭，导致了对文档的误读，堆积了更多的 bug。而这些 bug 由于硬件或者开发环境的不同很难复现。但是这种 bug 没有补丁。

这里也有一些功能建议的 bug，并附上了补丁，但我们通常会犹豫是否接受这些更改，因为这些关注点没有什么用处。比如不具有同类语言的一些功能，或者向后兼容。不打破所有的时间很难接受这些补丁。

另外，核心开发人员自己都有大量的工作，没有人来分担合并补丁到 Python 核心代码的工作。所有如果没有核心团队关注的补丁和功能，一般不会插入到合并流程。

在一个公司里，这些东西是有些不同。人们付款给人做一些枯燥乏味的工作，但要是开源的话你必须自愿完成那些不愉快的任务。一些核心开发者已经做这些枯燥乏味的工作太久了，他们希望从这些工作中脱身。一些开放的 bug 在 bug 追踪器上有很长的历史，这是有很多原因的。

最终，总是有很多统计效应被忽略。如果你随机注意到一个 bug，包括已关闭的 bug，你可能会得到一个已关闭的 bug。许多 bug 很快就被关闭，并且 bug 被简单地修复，类似于那种快速修复。但是，开放的 bug 的平均寿命是随着项目年龄的增长而线性增长的，他说。

GIL

有些听众问到global interpreter lock（GIL），想要更深入了解这个问题，以及这个问题是如何解决的。Van Rossum笑着反问道：“你有多少时间？”他简要的讲述了GIL产生的历史。在Python诞生后，多核计算机出现了。当线程运行在不同的内核中时，两个或更多的处理器要更新同一个对象便产生了竞争机制，特别在Python垃圾回收处理机制中。

一个合理的解决方案就是给每个对象上锁，这样能保护数据不被多路存取破坏。但结果导致当没有锁的竞争时，上锁和解锁操作代价高昂。一些实验表明，不需要上锁的单线程程序性能会因此降低2倍。这意味着只有在使用三个或多个线程或内核的程序会从中获益。

因此，GIL 诞生了（尽管这个名字在它被添加到解释器后很久才出现）。它是一个立刻有效锁定所有对象的单一锁，这样所有对象访问将排序进行。目前的问题是，10年或15年以后，多核处理器无处不在，人们想要不必进行多重处理就可利用它们（例如，使用独立的进程而不是线程通信）

他说，如果你当今想要设计一种新语言，要让它没有易变的对象，或者有限的易变性。然而，听众中传来“这就不是 Python 了”。Van Rossum 赞成的说：“你说出了我要说的话”。GIL 周围有很多开发者不断的努力，包括 PyPy 软件事务内存（STM），以及 PyParallel。其他开发者也撞破了脑袋在想解决办法。如果有人知道有什么办法能够移除 GIL 且让语言保持 Python 特性，Van 和其他人将很乐意听到。