Barry Warsaw，美国软件工程师，Python 基金会领英团队成员。Barry 曾在 Canonical 工作过 10 年，在该公司专门负责 Ubuntu 与 Debian 里 Python 生态圈开发，他还是 Python 开源邮件列表管理器 Mailman 的项目负责人。Barry 曾经是 Jython 主责维护者、Python 发布管理员、PythonLabs 的成员。Barry 很早就是 Python 的核心开发人员，还是多个 Python 增强提案（PEP）的作者，多个 Python 支持库的维护人员。
访谈主题：PythonLabs、Python 的未来，Python 2.7 与 3.x 对比
Mike Driscoll：您是怎么当上程序员的？
Barry Warsaw：我很小的时候就开始编程了，那时的计算机还称不上是计算机，只能说是电传打字机，不过可以连接到学校的主机，我算是从电传打字机起步的。
我学过 BASIC，觉得它非常有趣。 还记得那年暑假，有所学校的孩子用同类型电传打字机侵入了教委主机。第二年，教委就淘汰了所有学校的电传打字机，给学校配备了搭载 6502 处理器的个人电脑。学校老师都不知道该怎么用这些电脑，结果是我教的他们。
辅导员觉得我干的不错，帮我联系了国家标准局（NBS）的暑期实习工作，这是在马里兰州盖瑟斯堡市的一家联邦研究所。我在那里爱上了编程的分享精神，还学会了团队合作。
Driscoll：那您高中期间都是在 NBS 工作吗？
Warsaw：是的，我整个高中还有大学都在 NBS 实习。后来我还在现在的国家标准与技术研究所（NIST）全职工作了一段时间，一直干到 90 年。
在 NIST 的实习与全职工作让我大开眼界，一开始，我并不清楚业界的真实情况是什么样的，也不知道到底怎样才算专业程序员。
我那时在机器人团队工作，但并未参与太多机器人业务，主要还是在为工业自动化机器人设计图形化用户界面，这项工作非常有意思。我从这项工作起步，后来开始做系统管理。几年后，我们团队配备了很多台 Sun-3，那时我学了 SunOS、Unix、C 语言、Emacs。
我大学本科学的是计算机科学，虽然学得不错，但其实我的编程技能都是在 NIST 学的。我认为，大学课程不足以让人面对工作中的挑战。
我和一些实习生聊过，他们在大学，至少在本科期间，居然连 Git 版本控制系统都没学过。我觉得这太不可思议了，大学教育和程序员实际工作脱节太严重了。等这帮孩子大学毕业后，发现学的东西与实际工作完全都是两码事儿，直接就懵圈了。
Driscoll：您觉得 Python 是否是程序员新手通往实战编程的坦途？
Warsaw：是的，我最近和一些用 Python 的孩子交流，发现他们一般都会用 Github 处理项目，甚至还会参加 Python 大会，参与冲刺活动。
这些孩子通过这种方式积攒了很多现代软件工程的实践经验，所有的收获都是实实在的，比如，如何提交 pr，怎么处理 bug。我向身边的年轻人推荐 GitHub、GitLab、Bitbucket，他们对这些很感兴趣，还会积极参与。
Python 是最吸引人的社区，这个社区欢迎不同背景的人。Python 社区里的人都非常友善，我们兼容并包，不拒绝任何人，还会指导新人。所以我告诉学生，如果你们想以正确的方式学习，就一定要加入 Python 社区，还要积极参与，这样做，绝对会受益颇丰。
Driscoll：您自己是怎么迷上 Python 的？
Warsaw：1994 年，我认识了 Roger Masse。他的女朋友（后来成了他的老婆）和我老婆是闺蜜，我们经常聚在一起搓饭。Rog 和我都是极客，我们有很多共同语言。
Rog 那时刚到弗吉尼亚州的国立创新研究集团 （CNRI） 工作，CNRI 是 TCP/IP 之父 Bob Kahn 与 Vint Cerf 创建的 。94 年夏末，我也去了 CNRI 工作。
我负责的项目是 Knowbots，主要是把一些小型软件代理器捆绑在一起，转移到另一个host 里。Knowbots 会在另一个 host 里执行操作，在互联网里查找信息。为了实现这一目标，我和 Rog 开始在 NeXT 平台上用 Objective-C 开发这个项目。
没过多久，NIST 的一些朋友告诉我，有个荷兰佬要为他开发的编程语言搞一个小型研讨会，他们问我有没有兴趣，我为此还特地做了一点背景调研。你能猜到的，这个荷兰佬就是 Guido van Rossum，至于那门编程语言自然就是 Python。我回复他们：“没问题，我们一定去。”
我们觉得 Python 非常适合手头上的这个 Objective-C 项目，希望能和 Guido 交流一下想法，看看能不能用 Python 编写 Objective-C 脚本。
研讨会于 94 年 11 月举办，当时，参会的只有 20 个人，我们一下子就迷上了 Guido 和 Python。他这个人很放的开，也很酷，那次研讨会非常成功。Guido 和我都是 Emacs 的粉丝，我们聊了一下怎么才能让 Python 的 DocString 的语法更规范，至少应该学学 Emacs Lisp 的 DocString 语法。
研讨会后，我们一起回到 CNRI，探讨怎么才能让 Python 更好用。有个同事突然提议，“干嘛不把 Guido 招进来？” 当时，我们不清楚 Guido 愿不愿意来美国，也不知道他对用 Python 开发这个 Objective-C 项目是否感兴趣。但结果是 ~~ 他愿意，95 年 4 月，Guido 来了美国，开始在 CNRI 工作。
我们把很多基础设施从荷兰转移到了弗吉尼亚。那时，所谓的基础设施其实只是 CVS[1] 源代码库。我们把 CVS 代码库迁了过来，为 Python 做了很多系统管理方面的工作，当然，还要开发 Python。
当时，我最擅长的是 C 语言，我们一起做了很多 Python 的 C 内核与标准库方面的工作，Python 1.2 是在 CNRI 推出的第一个发行版，Python 现在的很多内容都源于这个版本，就算现在的 Python 3 依然秉承了当年那个版本的韵味。不过，Python 后来添加了很多非常赞的新功能，一般人已经看不出来这其中的关系了。
我们当时做了很多 Tcl/TK 图形化工作，此外，我还依稀记得当时 Python 已经支持类，但却没有关键字参数，当时的函数操作有些荒谬，就算大多数参数值是 None，也必须要传递全部参数，这就是为什么后来我们添加了关键字参数。不管怎么说，CNRI 是个好地方，与 Guido 合作开发 Python 也让人很开心。我们的合作一直都非常愉快，就算后来 Guido 离开也没有改变。
Driscoll：Steve Holden 说您是 PythonLabs 的成员，您是创始人之一吗？
Warsaw：是的。2000 年，我们几个离开了 CNRI，想依托 Python 寻找发展机会。当时一共有 5 个人，Tim Peters、Jeremy Hilton、Fred Drake、Guido，还有我，Roger 留在了 CNRI。我们管这个小团体叫 PythonLabs，但其实这不过是我们这几个人的玩笑话，从来没有当真过。
我们加入了 BeOpen，但几个月后就离开了，一起转移阵地到了 Zope 集团。我们这个五人小组包括了从 CNRI 出来的人，还有 Tim Peters。有一次我还在邮件列表里和 Tim 开玩笑，问他 PythonLabs 是不是还存在。如果去过 pythonlab.com 网站，就会看到 Tim 的回答有多搞笑。
Driscoll：你们在 PythonLabs 里有各自明确的分工吗？
Warsaw：真没有，只能说 Guido 算是 Python 项目的带头人。
我已经记不清细节了，尤其是在 Zope 时的事。我们在 Zope 都有各自的工作，但也会聚在一起开发 Python。
我们自己找感兴趣的活儿，比如开发内核、推出新功能、修复 bug、完善基础架构。当时 Python 社区可比现在小多了，所有这些事都得我们自己做。
Driscoll：当年你们要为 Python 做这么多事情？
Warsaw：当年的事情我记不清楚了，但肯定有人会做 Python 的考古工作，找出哪些功能是在什么时候推出的。我只记得重要的事。
我记得在 CNRI 时最早做过的一件事是 Roger 和我一起搞的 Python 重命名。当年，Python C 源代码的命名空间远没有现在的 C API 这么清晰，所有对象都叫全局命名空间。
随之而来的问题是，Python 嵌入时会失败，因为这些名字会与它们自己的标识冲突。所以我们要重命名，要查看整个 C API 内核，还要清理命名，这样，才能把 Python 嵌入到其它 C 应用。这是我们刚接触 Python 时干的第一件事，正因如此，我才能记得这么清楚。
最开始在 Python 研讨会时，我并不是特别理解 metaclass 。那时，我并不太关注这点，不过到了 Python 2.2，我们真的需要正确使用 metaclass，还要修复经典类的语义问题。
当年，我们还各种讨论怎么才能让新样式类顺利运行，让它可以像继承新实例一样，从一个类型（type）继承，继而定义新的类型。新功能太多了，我们总能找到让自己感兴趣的事情，然后全情投入进去。
Driscoll：我好像记得 Python 最初的邮件模块是你开发的，你还记得吗？
Warsaw：我记得这事，我们当初干的事就包括把 Python 的邮件列表转到 CRNI，这个邮件列表当年部署在 CWI，CWI 是荷兰一家研究所，Guido 来美国工作前，他就在那里工作。
Python 邮件列表当时是运行在 Majordomo 上的，这是当年最流行的邮件列表软件，它是用 Perl 开发的。把 Python 邮件列表迁移到 CNRI 后，我们发现有很多需要改进的地方。这里要提一下 Ken Manheimer，他在 Mailman 开发初期起到了非常重要的作用。
我们在 CNRI 安装了 Majordomo，但要让它适合我们的需求是件麻烦事儿。我们不想用 Perl 开发，毕竟我们是搞 Python 的啊！
我们有个朋友叫 John Viega，他当时在弗吉尼亚大学上学。Dave Matthews 乐队成名前，John 和他们就是朋友了。John 想用 Python 开发个小型邮件列表管理器，用来联系乐队粉丝，给粉丝发公告。他把邮件列表管理器写出来没多久，我们就听到了风声。
我们觉得他开发的管理器应该也可以用于 Python 邮件列表，有个用 Python 开发的邮件列表管理器肯定更好。我们想找 John 要了一份邮件列表管理器的副本，但他把代码磁盘给搞丢了，好在 Ken 恢复了一份副本，我们才能开始进一步开发为 Python 社区邮件列表。
这个邮件列表管理器就是后来的 Mailman，我们把它加到了 GNU 项目里，遵从 GPL 开源协议。我个人参与了很多 Mailman 的工作，这个项目很有意思，我非常喜欢这个项目促进沟通交流的一面。
早期 Mailman 还配置了网页界面，这点特别酷，Majordomo 当时可没有这样的功能。在我看来，这是 Mailman 成功的决定性因素之一。
我还注意到当时没有好用的，兼容 RFC 的邮件解析软件，真没有！标准库里虽然有 rfc822 模块，但已经非常落后了，新的电子邮件信息格式标准早就推出了。
很明显，rfc822 并不适用。我只好开发了 mimelib 分支，添加了对 MIME 架构的支持：使用不同的 MIME 类型[2]与图片编写邮件。还定义了描述电子邮件信息，尤其是 MIME 信息的模型。
我们希望它能构建程序化电子邮件信息树，还为它配备了把 Python 2 字节字符串提交给电子邮件信息树的解析器。用这个解析器可以把电子邮件信息树表示为电子邮件信息。然后可以操作这些信息，把这个信息树传递给生成器。生成器会把信息树扁平化为字节表示的电子邮件信息与 MIME Boundary 等信息。
我们还尝试与 RFC 兼容，开发的效果非常好，但这些标准非常复杂，现在还能发现不足与 bug。但不管怎么样，mimelib 作为独立第三方支持库，还算说得过去。然后我开始在 Mailman 里用 mimelib，mimelib 作为第三方支持库的好处很明显，可以在 Mailman 之外独立开发，需要的时候，把它当作支持项引入就可以了。
我记不清楚这是什么时候的事情了，但我记得 mimelib 特别稳定以后，Python 发布了新版，当时用的 API 非常不错。我们把 mimelib 加到了标准库里，把它命名为 email 包，这个名字更贴切，因为这个包里的内容不只是 MIME。
这就是 Email 包的来历，这个包是基于 Python 标准库里的 rfc822 模块开发的，是从为 Mailman 提供支持的 mimelib 进化来的。我曾开玩笑说，PyCon 小组会应该叫老爷爷的 Python 时光！我们接触 Python 真的好久好久了，我们应该说：“小子！过来，围着篝火坐成一圈，老爷爷要讲 Python 当年的故事了。”
Driscoll：讲完了 Mailman，您能再分享一下作为项目带头人的经验与教训吗？
Warsaw：我可算不上好的项目带头人！我的兴趣爱好太多，很难在一个项目上投入太多精力。
好在 Mailman 项目的核心开发者都能力超强、热心、友善。我在 PyCon 时就是把核心开发者聚在一起，在各种社交场合找人闲聊，一起研究技术，保持技术领先。
Mailman 已经推出很久了，但却老当益壮。我认为项目带头人一定要 Open，要相信核心开发人员，要能放权。卓越的网络设计者既要能真正理解技术，还要能设计美观、有趣的界面。我觉得这样很好，可以让我专心干些真正感兴趣的事。
我们举办过一些谷歌暑期编程项目，有一名核心开发者就是在这些活动时加入的，他刚刚完成了 Docker 镜像与胶水层的很多工作。与团队成员相处甚欢的感觉很棒，他们都是非常聪明、友善的人。
拥有能推动 Python 社区理念的开发人员至关重要。Python 社区开放、友善，乐于悉心指导新人。我认为，要对所做的事情保持开放的心态，花些时间分享专业知识，能给你带来十倍回报。
Driscoll：您在 Mailman 项目时遇到过意想不到的问题吗？
Warsaw：当然有。那时，我想的比较简单，Mailman 是个免费软件，我们只不过是把它发布到网上，没想过什么人会用，以及会用它干什么。
我们没有对 Mailman 做任何控制，也没有告诉大家什么能做，什么不能做。大多数人都很规矩，比如自行车俱乐部内部沟通或教学研讨。但也有人用 Mailman 做恶，比如群发垃圾邮件。这是个特别严重的问题，用户曾告诉我们有人肆意滥发垃圾邮件，我们甚至还收到过不少恐吓邮件，这真的让人很搓火。
垃圾邮件给受害者带来无尽烦恼，受害者不知道谁给他们发的垃圾邮件，心中的怒火无处发泄，他们会在网上开始搜索，直到找到我们。
现在，我们精心编制了公告，声明绝不姑息发送垃圾邮件行为，不允许任何出于非法目的使用 Mailman 的行为。我们鼓励大家注册后再使用 Mailman，但没法真正控制人们如何使用 Mailman。
我们没有任何 Mailman 管理员权限，但受害者联系我们的时候，往往怒气冲天。通过这件事，我了解到，让大家知道 Mailman 的背后有人存在是有帮助的。我们会做一些调查，看看能不能找到联系人，或者找到他们的主机托管商。就算最怒火中烧的受害者一般也会感谢我们的帮助。
这是我们早期遇到的最大的问题。很多人往我个人邮箱里发送充满污言秽语的邮件，这让我非常难过。互联网上真是什么样的人都有啊！
Driscoll：编写 PyDev 周报系列文章时，我记得您曾提过您在 Canonical 工作。在 Linux 发行公司工作是什么感觉？
Warsaw：感觉很好，我在这家公司干了十年，今年（2017年）四月才离职。我特别喜欢这家公司，可以促进 Python 社区在 Ubuntu 与 Debian 系统上的发展。
在 Canonical 工作可以帮助 Ubuntu 与 Debian 等 Linux 发行版的用户，还有这些平台的 Python 用户。我是 Python 的核心开发者，出现任何问题时，我很快就能知道 Debian 或 Ubuntu 哪里需要修复，我还可以了解这些问题是否需要回传到 Python 或 Python 的支持库。
正因如此，我才有机会密切参与很多 Python 项目。我还能直接接触 Python 本身，以及我认为需要在 Linux 发行版里改进的各项内容。这样的经历非常有意义，能有机会做这种工作，我很开心。
Driscoll：您在 Canonical 具体负责什么？能介绍一下吗？
Warsaw：我是底层团队成员之一，这是管理 Linux 发行版管道层的小型团队。
系统最底层是内核。但我们不做内核相关的工作，内核团队是独立的。但在内核之上，还有引导过程、编译器、工具链等。涉及到存档时，要确保这些模块稳定、成熟。所有这些模块都在内核之上，但在桌面应用之下。
底层团队的另一项工作是负责语言解释器。不论是写操作系统脚本，还是构建过程应用， Python 都是最常用的语言。它是 Ubuntu 与Debian 等多种 Linux 发行版里最重要的编程语言。
我的工作之一就是确保 Ubuntu Python 生态系统的健康，包括让大家都能顺利升级到 Python 3。推出新版 Python 时，虽然我不直接负责解释器，但我会处理所有与之相关的支持包。
为了把 Python 3.5 设置为 Ubuntu 的默认版本需要做很多工作，这是一个漫长的过程。那时，很多支持包要么还没开发出来，要么就是在新版 Python 里有 bug，这些都是必须优先解决的。我当时在 Ubuntu 上做的主要工作就是维护 Python 生态系统正常运转。
我关注的重点是 Ubuntu 工具，还有 Ubuntu 开发者使用 Python 的痛点。我要做的是找出哪里需要改进，怎么改进。比如说，如果 Ubuntu 上的 pip 或 setuptools 出了问题，我就要赶紧修复，我的任务就是发现用户使用 Ubuntu 时的痛点。
另外， 我还是 Ubuntu Python 用户的咨询顾问。只要有人提出 Python 方面的问题，我就得帮忙，回答问题，审核代码。
我还要协助社区里的人。如果社区里有人问 Ubuntu 里 Python 如何工作，或有任何问题，他们要找的人就是我。这里很多工作都是社区驱动的，如果想让发行版成功，必须在社区里投入诸多资源。每种 Linux 发行版都会向社区里投入大量的资源，如果不这样做的话，该发行版很快就会退出历史舞台。
Driscoll：接下来咱们换个的话题。您觉得现在 Python 是适合人工智能与机器学习的编程语言吗？
Warsaw：Python 这种胶水语言非常适合机器学习，可塑性强，而且非常成熟，甚至可以用来开发大型系统。这就是为什么 Python 现在在数据科学领域越来越流行，这些领域里技术不是核心，与研究的核心内容相比，编程只是第二位的。
Driscoll：怎样才能让 Python 更适于人工智能与机器学习？
Warsaw：我不确定 Python 是否需要改变，但 Python 生态系统确实还有精进的空间，应该推出更多人工智能与机器学习支持库，让这些支持库可以更轻松地整合进 Python 应用、框架与其它支持库。
Driscoll：您现在做什么工作？能满足下我的好奇心吗？
Warsaw：我两周前才刚到 Linkedin 工作，我很喜欢这家公司，这是一家了不起的公司。他们在很多地方使用 Python，我干的还是 Python，在 LinkedIn 负责 Python 开发的工作，我喜欢这个团队。
LinkedIn 的使命很伟大，我非常认同这家公司为之奋斗的目标。它的使命就是在联结世人的基础上，为大家提供各种就业机会。LinkedIn 帮助我找到了一份工作，而这份工作恰恰是为 LinkedIn 工作，是不是很有意思！
LinkedIn 还提供很多服务。让每个人都能找到合适自己的工作，实现更理想的职业生涯，这是我喜欢干的事。
Driscoll：可以说您对 Python 了如指掌，那您能讲讲 Python 这门编程语言的未来会是怎样的吗？
Warsaw：这个问题有意思。虽然接触 Python 已经 23 年了，但我无法预测 Python 的未来，这就像 94 年无法预测如今的计算机世界一样。
纵观当下的科技，手机、物联网、云技术，都那么引人入胜。计算机世界在飞速发展，我无法预测五年内 Python 的走势，更别提十年以后了。
我坚信 Python 的未来将会一片光明，但 Python，尤其是 CPython，Python 的 C 实现，会面临挑战。存在这么久的编程语言都会面临挑战。Python 当初的目标是为了解决 90 年代的问题，但如今的计算机世界与当年已经不一样了，而且还在不断变化。
Python 面对的挑战包括如何提高性能、如何适应多核与多线程应用。现在肯定有人在研究这些东西，肯定还会出现类似 PyPy、Jython、IronPython 这样的 Python 实现。
不提各种 Python 实现面对的问题，Python 作为一门编程语言，其最大的优势就是适用于各种规模的项目。一个人为了解决问题在笔记本上随便写些脚本可以用 Python，七八个人的小型开源项目可以用 Python，几百个人的大型项目可以用 Python，数千人的超级大型软件项目还可以用 Python，这就是 Python 的优势。
Python 的另一个优势在于，新人入门很快，学起来容易，很快就可以用 Python 做些实事。Python 新手可以找一些从未见过的 Python 项目源代码，花点时间，很快就可以轻松上手。 与项目人员规模类似，Python 还遇到过一些别的问题，但我觉得那些问题已经被类型注释等功能解决了。
超大规模的 Python 项目里一般都会有高级与初级开发者，从静态类型的语言转型过来的初级开发者往往要下一番功夫才能理解如何用现有的支持库与应用。
因此，很多开发大型 Python 代码库的公司都采用了类型注释功能，这个功能对应用的性能也许并没有什么帮助，但能帮刚上手的程序员快速了解代码。我觉得这将帮助 Python 在很长时间内持续提高大规模开发的优势。
对我来说，这门编程语言适应各种规模的能力，与 Python 社区热情开发的特质是 Python 经历了23 年之后还如此引人入胜的两大优势，这两大优势还将继续支持 Python 未来也保持这种吸引力。如果能解决那些技术限制，我们就能让 Python 在未来的 20 年里继续保持成功，并不断成长。
Driscoll：您知不知道 Python 还会推出什么新功能，您喜欢哪些 Python 功能？
Warsaw：我的另一个朋友，Eric Smith，也是核心开发者，提出了一些非常不错的功能，很难想象 Python 以前怎么就没有这些功能。
f-string，格式字符串是 Python 3.6 推出的新功能。我只在一两个项目里用过 f-string，因为这是 Python 3.6 里的功能，但我太喜欢 f-string 了。
我还喜欢 contextlib，也很喜欢新推出的 Python 3.7。虽然每次推出新版我都会这么说，但 Python 3.7 真是最好的版本。这个版本推出了很多新的支持库，改进了对 asyncio 的支持，性能也提高了不少。Python 开发和以往一样充满活力，我相信工作流的改进（例如，从 Git 切换到 GitHub）会吸引更多人参与 Python 开发。
有些人的想法很疯狂，比如 gilectomy，不过我喜欢，就算他们没有成功，也为将来的开发探索了一条新路。C Python 实现很容易理解，也容易改变，为了让这个平台更利于实验与改变，其实走了很长的道路。
Guido 一直都是 Python 社区的大管家，那些元老级开发者也都很有远见，虽然现在的 Python 与 20 多年前相比已经迥然不同，但它给人的感觉还是那个设计精良、始终如一、易学易懂、遇强则强、遇弱则弱的编程语言。
Driscoll：您对 Python 2.7 长盛不衰的现象是怎么看的？
Warsaw：我们都知道 Python 3 势不可挡，Python 2 剩下的日子已经屈指可数了。我曾经把鼓动 Ubuntu 用户使用 Python 3 当成自己的使命。在 LinkedIn，我非常开心，现在参与的项目用的都是 Python 3，Python 3 比 Python 2 好多了。
一般用户不会意识到 Python 3 里推出了多少新功能。异步 I/O 这个功能就非常棒。我在很多地方都用这个功能，Python 3.4 推出的这个功能太赞了。就算 Python 3.5 推出了新的基于 I/O 的 async 关键字，asyncio 还是那么赞。
Python 3 里这样的功能太多了，只要用过这些功能，就再也不想用回 Python 2 了。你会觉得 Python 2 太原始了。我喜欢 Python 3，我个人的开源项目只支持 Python 3。支持 Python 2.7 是件苦差事，就算有些支持库向后兼容 Python 2，但 Python 2 里还是欠缺很多常用的好功能。
我坚信已经到全面拥抱 Python 3 的时候了。哪怕出于业务原因还要支持现有 Python 2 代码，我也不会再写一行不支持 Python 3 的代码。
升级到 Python 3 从来就不是什么难事，虽然仍有很多支持组件不支持 Python 3，但一般这都是因为那些支持组件已经被废弃了。升级到 Python 3 确实需要占用不少资源，还要谨慎规划，但任何一家经常要解决技术问题的公司都应该把升级 Python 3 列到自己的计划里。
怎么说呢，Python 2.7 能存在这么久确实很了不起。我认为 Python 2 有两大好处。第一个是 Python 2 的版本非常稳定，每次版本更新的周期都很长，大家不用每隔 18 个月就升级一次 Python，这是 Python 3 典型的开发升级周期。
Python 2.7 的生命周期这么长，还使得它的生态系统可以赶上 Python 3。
Python 2.7 的长盛不衰也让 Python 2 的生态系统能赶上 Python 3。因此，那些积极支持 Python 2 的人有时间打磨 Python 2 的生态系统。我们现在拥有的工具、经验与专业知识已经足够强大，可以确保升级到 Python 3 的成功几率最大。
Python 3.5 推出时就已经到了转折点。就算不看数据，也早过了争论是否要选择 Python 3 的时期，起码新项目不会再考虑 Python 2。Python 官方团队会在 2020 年中期停止对 Python 2.7 的支持，我觉得这么做是对的，但还应该再早点！很多时候，你会觉得用 Python 3 开发更有乐趣。在这里，你会感觉到 Python 开发者最有精力、最有激情的一面。
Driscoll：您希望 Python 未来新版出现哪些改进？
Warsaw：我最近一直在想 C 扩展模块开发方式做出的重大改变。采用了 Cython 这样的高阶语言与生成扩展模块的工具后，终于可以不再操心那些烦心事了，我们为 C API 改进奠定了基础，并与所有现存的扩展模块脱钩。
我们尝试了很多打破 C API 的内核变化，比如移除全局解释器锁（GIL），还尝试了采用传统型垃圾采集器。研究过 gilectomy 项目（移除 GIL 的实验性分支）你就会知道， 这个项目非常复杂，因为要尽量兼容现有的 C API。如果能在打破这一限制的同时，不破坏对第三方模块的源代码级兼容性，就可以在改进内部事物的时候更加自如。
Driscoll：谢谢您，Barry Warsaw。
-
CVS，Concurrent Versions System，是一种C/S系统，开源软件管理中常用的代码版本控制软件。 ↩
-
MIME，Multipurpose Internet Mail Extensions，即媒体类型，MIME 是一种用于表示文档、文件或字节流的性质和格式的标准。 ↩