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 和其他人将很乐意听到。
PyPy
他被问到 PyPy，他是否使用它，是否有一天它会成为默认的解释器。他不使用 PyPy，但他下载了一下，玩了几分钟，他喜欢他看到的东西。他在两种模式下使用 Python，或写些小的脚本完成一些事情，他只使用一个已经在他系统已经内置安装的解释器，或者做为一个 Dropbox 的工程师将 Python 布署到集群。
Dropbox 集群运行修改过的 Python 2.7，他说，这引起观众的笑声。“我说过，这不是秘密”，他说。因为 PyPy 比较快，Dropbox 的一些部分在使用 PyPy。但公司担心一些小的不兼容会导致一些不容易追踪的 bug。“我们已经遇到了太多这样的问题。”
PyPy 证实了你可以比 CPython 更快的执行 Python。它同时提供了一个测试平台，在这个平台上可以测试像 STM 这样有意思的创意。但是保守原则让人们只在需要加快速度时使用 PyPy。这样做带来的问题时，当你发现时，你已经在很多机器上部署了以至于很难迁移。因此，这很像迁移到 Python 3 上遇到的问题。
Dropbox 有很多对第三方的依赖，有些甚至不能在它的源代码上重构。这对那些在生产环境中使用了成千上万行 Python 代码的公司也是同样的，他发现 Google 也是这样，要迁移很困难。
总之，PyPy 是一个“非常酷的项目”。但是它有很多复选框，需要变得更易检查。他半开玩笑的建议说，或许 PyPy 需要从 DjangoGirls 中租用 Ola and Ola 来创建一个更大的项目社区。
最喜欢的
接下来的 5 个小问题是他喜欢的东西。喜欢的 web 框架？他说他在任何一个框架中只写一个 web app，他最后尝试的是 Flask。喜欢的测试库？他主要使用标准库中的 unittest 和 mock。编辑器？他现在使用 Emacs，但是最开始使用 vi（两种都得到不同听众的喝彩）。他仍然偶尔使用 vi（或 Vim），但是使用 5 分钟后，他就要花上 15 分钟重新适应 Emacs。
除 Python 外最喜欢的语言是什么？他过去常常说是 C 语言，但是“有点无聊”。他信赖的人告诉他现代 C++ 是个优秀的语言。他喜欢 Go，但是没有用它编写任何有意义的东西。当他与设计师交谈后，他喜欢从 Python 偷了一堆东西的 Swift 的外表。从语言中抄袭你喜欢的不好的东西并以一堆不合逻辑的特性而告终很容易，但是 Swift 的设计者看起来没有这样做。最后，喜欢的异常？在更多的欢呼和笑声中，他轻轻地笑着回答是键盘中断。
他所讨厌的
最后的问题是他讨厌 Python 哪些方面。他马上回答：“一切与打包发布有关的事情”。总是有与版本交叉和依赖有关的问题引起“永无止境的混乱”。他害怕同事跑过来问他“一个简单的 Python 问题”，有一半是某种输入路径问题而且没有什么简单的解决办法。
