原创：呆鸟的Python大咖谈 源：Python大咖谈

Marc-André Lemburg，德国软件开发者、企业家，eGenix 公司创始人与 CEO，该公司专注提供 Python 培训与咨询服务。Marc-André 是 Python 核心开发者，也是一系列 Python 主流扩展插件的作者。他是 Python 软件基金会（PSF）创始人之一，担任过两届 Python 软件基金会董事。Marc-André 还是 Python 杜塞尔多夫大会的联合创始人与 EuroPython 社区（EPS）的主席，他常年参与各种 Python 会议，发表各种演说。

访谈主题：mx 包、Python 软件基金会、Python 2.7 与 Python 3.x

Mike Driscoll：您为什么会当程序员？

Marc-André Lemburg：算是子承父业吧，我父亲是 IBM 的员工，我很小就开始接触计算机编程了。

我喜欢技术与创造，但 70 年代后期，计算机可不是小孩子能接触得到的。我只能在纸上写“程序”，然后想像真正的计算机如何执行这些代码。

11岁 那年，父亲买了一台 Sinclair ZX81，自此之后，我开始正式学习编程。一开始，我学的是 BASIC，后来又学了 Z80 汇编器。ZX81 超级慢，但汇编器非常有意思。我根据 Z80 手册, 先逐字逐句地把操作码组合成程序代码，再把操作码转换为十六进制, 手动输入到 ZX81 的十六进制编辑器里, 最后才能运行例程。

Sinclair ZX81

这些努力都没白费，例程运行速度比 ZX81 BASIC 快的多。如果代码里有 bug，一般要重启 ZX81，还要重新打开程序，重新加载所有组件。当时还是卡带式驱动界面，这些操作要费好长时间，为了避免浪费时间，我还学会了注重性能与细节。

大约两年后，父亲又买了一台 IBM PC1，我从此开始学习微软 BASIC、Turbo Pascal、Turbo C。在校期间，我一直痴迷于计算机，上大学后，我开创了第一家公司。

IBM PC

Driscoll：您是怎么用上 Python 的？

Lemburg：94 年，研究 Hobbes OS/2 时，Python 是该系统 1.1 版内置的编程语言之一。

我一下午就读完了 Guido van Rossum 的教程，我发现这才是自己一直想要的编程语言。Python 包括了所有重要数据结构，简单、易用、语法清晰，无需显式管理内存，不用括号定义代码块。

我那会儿用的最多的是 C，经常要面对各种系统语言难题，比如，内存分配、指针算法、溢出、segfaults、调试器长会话、漫长的编辑-编译-运行-调试周期等。

Python 有我想要的一切：支持交互试验的解释器、编撰精良的文档、近乎完整的标准库、体验优秀的 C API，具备 Python 对接现有 C 代码的所有接口。还有个特别有意思的小细节：这个解释器用自己的数据结构实现自己的内核。

Driscoll：能介绍下您是怎么开公司，当老板的吗？

Lemburg：我 17 岁开始干 IT，1993 年上大学时，开创了第一家公司，那个公司叫 IKDS，我还是自由撰稿人，为那些想挺进新市场，开展网上业务的本地公司写文案。

1997 年大学毕业时，我借助以前开发网站引擎的经验，开发了一个新的网络应用服务器。我的目标是开发一个能轻松、快捷构建线上网络系统的系统。这个系统要用到面向对象编程、关系型数据库，还有简单优雅的 Python。

苦干了三年，我终于完成了第一个发行版，包括企业级产品所需的一切功能。2000 年初，我创立了一家有限公司，专门营销这个产品。开发这个应用服务器让我踏入了开源世界。

因为没有足够的资源进行整体测试，我决定开源应用服务器的基础模块。这就是后来流行一时的 mx 扩展插件。从商业角度来说，这个应用服务器不是成功的项目，当时市场上的用户根本不能理解这种产品好在哪里。

我只好专注为其它公司提供咨询顾问与项目运营服务，还对一个完全用 Python 开发的商务交易系统产生了浓厚的兴趣。还有一些类似的项目让我手忙脚乱，没有多少时间开发 CPython。

Driscoll：能详细介绍下您公司发布、并一直负责维护的 mx 扩展插件吗？

Lemburg：97 年开发网络应用服务器时，我开始开发 mx 扩展插件，主要是因为 Python 没有好用的通用型数据模块。

当时，只有一个老旧的，基于 Windows 的 ODBC 接口，但它并不是跨 Windows 与 Unix 平台数据库接口的好选择，不实用，性能也不高。为了解决这个需求，我开始开发 mxODBC。我想为 ODBC 驱动开发一个快速、可移植的接口，可以为应用服务器连接所有常用的数据库。

开发 mxODBC 的时候，没有好用的日期时间控制模块，这个问题弄得我很头疼。mxDateTime 就是为了解决这个问题开发的，多年来，它一直都是 Python 社区的标准，直到 Python 2.3 标准库推出 DateTime 模块。

为了快速解析应用服务器模板，我还开发了 mxTextTools 等其它 mx 扩展插件包。后来，还有人用这些扩展插件开发了解析引擎（Biopython 用它解析基因组数据），或用来实现用户定义语法解析器。

mxTextTools 的标记引擎有点像图灵状态机，用它解析原语非常快，还能与 Python 元组（tuple）一起使用。此外，还有几个可以用于解析搜索与替换结果的工具函数。mxTextTools 一开始只能处理 8 位文本和二进制数据。几年后，有个客户特地花钱请我升级这个工具，希望它能支持 Unicode。

还有鲜为人知的 mxStack 与 maQueue，这两个是应用服务器的数据结构。mxTools 是为应用服务器开发的一套快速内置包。mxTools 里的一些点子后来慢慢地成了 Python 的核心功能。

Driscoll：您是怎么成为 Python 核心开发者的？

Lemburg：刚开发 mx 扩展插件时，经常要处理 Python C API 及其内核。我为 CPython 贡献了不少补丁，1997 年底，我就成了 Python 核心开发者。

为 CPython 集成 Unicode 所做的贡献让大家都知道了我。1999 年，惠普授权 Python 财团（Python 软件基金会的前身）使用 Unicode，Guido 找到我和 Fredrik Lundh，请我们为 Python 添加 Unicode 功能。

Fredrik 负责开发新正则表达式引擎。我则负责为 Python 添加原生 Unicode 支持。2000 年，我们第一次发布了带 Unicode 的 Python，分别是 Python 1.6 与 2.0。我负责维护 CPython 2.0 的 Unicode 功能，一直坚持了十来年。

Driscoll：除此之外，您还为 Python 做过哪些贡献？

Lemburg：我为编码系统、平台模块、部分本地模块贡献过源码，还负责开发 pybench 套件，评测 CPython 及其补丁的增强效果，让 Python 运行的更快，让人感觉更舒服。

Driscoll：作为 Python 核心开发者，您遇到过哪些困难？

Lemburg：刚开始那几年，当核心开发者还是挺有意思的，那时的流程没现在这么正式。遇到的难题主要就是关于 Unicode 的讨论经常没完没了，最后就变成了口水仗。

我不知道是不是因为 Unicode 是处理文本的核心，还是说只是因为很多大神参与了这些讨论。大多数时间，我只能对他们的探讨报以苦笑，把它当个乐子。

从那时起，我们经历了几代核心开发者。培养新人非常不容易，要费很多唇舌。我们要不停向新人介绍 Python 开发运作原理，让他们别走弯路。

Driscoll：Python 是人工智能与机器学习的主要语言，您觉得这是为什么？

Lemburg：对于非计算机科学专业出身的科学家而言，Python 易学易用。科研工作中，调用外部支持库时，不用处理很多复杂难懂的功能。

Numeric（现在是 Numpy）推出后，IPython Notebook（现在是 Jupyter Notebook）、matplotlib 等工具让工作更直观，Python 让科学家关注于问题本身，而不是解决问题的技术。

Python 是非常理想的集成语言，可以轻松地把不同技术整合在一起。Python 用户只需要关注真正的问题，不用在实现细节上花费太多时间。除了让用户工作起来更轻松，Python 还是非常好用的胶水语言，用户可以开发与外部支持库集成的底层插件，这得益于 Python 具有非常优秀，且完备的 C API 访问接口。

Driscoll：Python 还能为人工智能与机器学习做出哪些改进？

Lemburg：Python 是人工智能与机器学习里最好的编程语言。Python 社区蓬勃发展让这门语言越来越好，Python 在这个领域的路还很长，未来也会更加光明。

Driscoll：您能介绍下 Python 软件基金会是怎么创立的吗？

Lemburg：Python 软件基金会的前身是 Python 软件活动小组（PSA），要想加入这个小组，每年都要支付年费。此外，还有知名度更低的 Python 财团，成员主要是企业，每年这些企业都会为 Python 开发资助一大笔钱。

这两个组织都不能真正为 Python 提供足够的支撑。Python 的版权分散在几个公司里，从 Python 的注册信息里可以看到。Zope 集团与 ActivePython 这两家为 Python 投资入巨资的公司启动了一个项目，希望成立一个新的非盈利组织，一次性解决这些问题。

这个项目就是后来的 Python 软件基金会，它是在第 9 届 Python 商务国际大会（IPC9）上创建的。当时，共有 16 名 Python 核心开发者与两家公司作为始创成员。包括 Guido 在内的核心开发者签署了贡献者协议，将他们为 Python 所做的一切贡献都授权给了Python 软件基金会。

最开始，Python 软件基金会只是维护 Python 发行版权的法律机构。后来，Python 软件基金会还获得了 CNRI 对 Python 的文字商标权。

2003 年，Python 软件基金会在华盛顿举办了首次 PyCon US 大会，这次大会为Python 软件基金会带来了不少资金，为开辟 Python 社区带来了新的可能。

PyCon US 大会的规模越来越大，赞助商的支持也越来越多，大会收入随之不断增加。几年后，Python 软件基金会终于发展成熟。那几年我在 Python 软件基金会董事会，为这一发展变化做出了不少贡献。

Driscoll：我知道您协助组织了第一届 EuroPython 大会，能介绍下吗？

Lemburg：2001 年，Python 与 Zope 的欧洲用户与公司希望能在欧洲举办 Python 大会，他们为此展开了长期的探讨。

当时，Python 研讨会与 IPC 大会基本上全都在美国，欧洲没什么 Python 活动。我也参与了这些探讨，不过他们一讨论起来就没完没了。后来，我加入了执行委员会，经过一番努力，EuroPython 大会终于召开了，这就是 2002 年 EuroPython 的由来。

与美国那种商务型 Python 会议的组织方式不同，EuroPython 的整个活动都是由志愿者支持的，当时的预算十分有限。EuroPython 比 PyCon US 更早，PyCon US 是美国举办的最早由志愿者支持的 Python 大会。

EuroPython 2002 是在沙勒罗瓦举办的，在欧洲第一次举行大型 Python 会议很有意思。EuroPython 非常成功，Guido 也参会了。现在，每年都有很多国家组织各种 Python 活动，EuroPython 不想与这些国家级 Python 活动竞争，但确实它也是在这些地方召开的。

Driscoll：EuroPython 这些年来都有哪些变化？

Lemburg：与最开始相比，EuroPython 的变化很大，2014 年已经超过了 1000 名与会人员。这个大会依然由志愿者支持运行，但已经不再是随随便便就能运作的活动了。

EuroPython 社区负责组织 EuroPython 大会，每年要在这上面投入很大精力。我曾是该组织的主席，并在董事会任职多年，每一年，这项活动都变得比上一年更专业、更正规。为了让大会顺利召开，每位董事会成员一般都要付出 200 到 400 小时的努力。

Driscoll：您觉得现在 Python 最令人兴奋的是什么？

Lemburg：我最喜欢的是 Python 对原生异步 I/O 的支持。新增的关键词终于可以让 Python 充分利用当今 CPU 的能量。

与之相反，我最不喜欢的是现在 Python 里的类型注释。类型注释让 Python 变得不再像以前那么优雅。虽然类型注释是可选项，但很多公司通过各种规定强制使用。越来越多的 Python 代码将会使用这些注释，这让 Python 与其它现代静态类型脚本语言变得没什么两样。

Driscoll：您怎么看待 Python 2.7？是否大家应该都升级到最新版？

Lemburg：是的，大家都应该升级到最新版，但同时还要考虑从 Python 2.7 升级到 3.x 要投入的工作量。很多公司拥有非常庞大的 Python 2.x 代码库，我自己的公司 eGenix 也是其中一员。从商业角度来看，升级到 Python 3.x 的意义不大，即便 2020 年后，Python 依然会存在两大阵营。

Python 2.7 拥有这方面的优势，是因为它是 Python 的长期支持版本。企业用户喜欢长期支持版本，不用辛辛苦苦去做版本升级。

我相信 Python 也会推出 3.x 长期支持版，用以维持 Python 在商业世界的成功。这种做法是与 Python 2.7 一样是非常可行的，对企业用户来说，很多年内，在这个版本上的投入会比较有保障。

Driscoll：您觉得 Python 未来发行版会有哪些改变？

Lemburg：Python 要调用让多核 CPU 更容易。异步 I/O 让单核 CPU 的应用更方便，但还不能解决多核 CPU 的部署问题。

移除全局解释锁（GIL），用更优的锁定机制替换 GIL 是一种办法，但要实现这一目标，还有一段漫长、崎岖的路要走。绝不能低估这件事的复杂性，很有可能会导致很多 C 扩展组件出现问题。GIL 是 Python 成功的核心驱动力之一，脱离 GIL 有可能会让 Python 大踏步后退。我们只能想办法为现有扩展组件提供一种相对平滑的升级路径，也许保留 GIL，让它在可控范围内更适合当今的现状。

我的看法是，应该研究其它方法，比如，让进程间的互通更有效，对用户更友好，甚至可以考虑添加新的关键词，支持自动并行代码。

Driscoll：谢谢您，Marc-André Lemburg。