Slashdot对Python之父的采访
Python 之父 Guido van Rossum 在 2013 年 1 月正式从 Google 离职后并正式加入 Dropbox。2013 年 8 月 19 日，Slashdot 网站发起了一个对 Guido 的访谈主题帖，网友在评论中提问。8 月 25 日，Slashdot 在另外一个帖子中汇总了“面向对象、函数式编程、PyPy、Python 3”等问题和回复。
从 Google 到 Dropbox
nurhussein 提问：“Hi，是什么促使离开 Google 去 Dropbox 的？你之前在 Google 主要做什么？以后在 Dropbox 会做什么？”
Guido：在 Google 呆了 7 年之后，我已经准备好生活里有一些变化，而这时 Dropbox 的工作机会正好契合了我的想法。以较高的层次来看，我的工作仍然没有什么变化：
- 花费一半时间来做作为 Python 的 BDFL 需要做的事情
- 在公司里作为一名普通的工程师（不是一名经理或者团队领导者）
- 做什么代码审查，架构和设计工作
- 处理很多 email
- 用 Python 来完成我的很多工作
一些细节当然是不同的。我在 Google 只做了两件事：最开始的两年我从事在线代码审查工具 Mondrian 的开发。这个工具从来没有被开源，但是它促使了 Rietveld 的产生，它被 Python，Go 和 Chromium 社区使用。在我加入 Google App Engine 后，我做了很多不同的事情，大部分是 Python 方面的事情。我 Python 的最后一个大项目是一个新的 Python 数据库 API，NDB。
我已经来 Dropbox7 个月了，我在这主要的工作是设计 Dropbox 数据存储 API。用到这个词来描述这个数据存储有点讽刺，但是不是我的错——Dropbox 数据存储和 Google App Engine 数据存储有一点重叠。
更讽刺的是，即使我做了如此多的设计工作，用 Python 完成了两个原型，但是我们上个月发布的 SDK 里面只支持 Java，Object-C 和 Javascritp。不过我正在完善它，这次采访拖累了我的进度。
为什么 Python 避开了一些常见的面向对象风格
由 i_ate_god 提问：“接口，虚类，私有成员，等等…为什么 Python 没有这些特性”
Guido：我能想到的有两个原因：你并不是真的需要它们，并且如果没有编译时的类型检查会很难实现。 Python 是作为一个臭鼬工厂的项目开始做的（没有被管理层支持和鼓励但也没有阻止），并且我希望能够快点出一些成果。这指引我移除了一些不是真正需要或者继续的特 性；这也让我进行运行时的所有类型检查，它限制了 Python 能够支持的特性。我也不是面向对象的忠实信徒——我只是想要一个简单的语言，它因为意外或多或少地变得有一些面向对象。
在现代的 Python 里，针对这些特性有一些粗糙的等价语法，但是它们并不是一直很好的工作，或者它们导致了一大堆的上面的执行，所以它们一般是被避免的，但是它们也有其用处。
函数式语言
由 ebno-10db 提问：“有些人提出，Python 是，至少一部分，是一种函数式语言。你不同意，我也是。只是有一些 map 和 filter 类型函数并不会让它成为函数式语言。以我的理解，这些函数是被一些思念 list 的人加到库里的，并且你已经尝试了几次去掉它们。总的来说，你不是一个函数式编程的粉丝，至少从 Python 上来看不是。
问题：你是否感觉函数式编程方法总的来说不是特别有用，或者它不是十分适合 Python？很希望听到你不同方面的原因。”
Guido：我并不是把一个想法做到极致的信徒，我试着在设计选择的时候走实用主义的路子（但不是“太”实 用主义）。我会衡量现实代码的可读性和可用性。有些地方 map ( ) 和 filter ( ) 是适合的，但是另一方面 Python 有列表推导。我不再讨厌 reduce ( )，因为我曾经只用 (a) 来实现 sum ( )，或者用(b) 可读性不好。所以我们添加了内建的 sum ( )，将 reduce ( )移除出内建函数，移到了一个工具函数里。
我对函数式语言的看法，就是它们都用非常强大的编译器，比如 Haskell。对这样的一个编译器，函数式泛型是非常有用的，因为它让大量的转变成为可能，包括并行化。但是 Python 解释器并不清楚你的代码的含义，这也是很有用的。所以，我不认为把一下函数式的思想加入 Python 是合理的，因为这些在函数式语言里是很有用的，但是不适合 Python，并且这会让代码对不使用函数式编程的人非常不具有可读性（这里指的是大部分程序员）。
我也不认为现在函数式语言的成果已经让它准备好成为主流。不可否认的是，我对于 Haskell 一些相关的领域并不是很了解，但是任何没有 Haskell 流行的语言都有它的实际用处，我也没有听过有别的函数式语言比 Haskell 更流行。对于 Haskell，我认为让很多编译器技术得到证明是非常棒的，但是它的“纯净”会是它被人接受的最大障碍。它的单一让它对于大部分人是不适合的。
多行 lambda 表达式
由 NeverWorker1 提问：“对于 Python，有一个最常见的抱怨就是它的对于 lambda 表达式的限制，也就是说一行里不能赋值。很明显，Python 对空格的处理是导致这样的主要原因。我已经花了一些事件思考实现多行 lambda 表达式的可能性，然后我能想出的最好方法是硬塞进一些不用的符号，比如C语言风格的大括号，这样最多有点乱。有没有更好的方法，你觉得这个功能会被添加上 吗？”
Guido：真的？我基本上从来没听到过那些抱怨，除了在 Slashdot 采访里提问题的人。
这确实是更好的方法，这里使用 def 关键字在本地作用域定义一个正规的函数。这个被定义的函数对象变成了一个本地变量，而这根使用 lambda 是相同的语义，除非这里用到了一个本地变量，并且这里没有任何语法的限制。例如，以下两种写法的语言是相同的：
def make_adder (n): __def adder (x): ____return x + n __return adder
然后这是使用 lambda 的表达式：
def make_adder (n): __return lambda x: x + n
Andrew Koenig 有一次向我指出了在一种场景下，lambda 是非常适合的，那就是你有你个很长的 list 或者 dict 包括很多 lambda 表达式，因此如果你想不用 lambda 实现的话，那么定义一大堆函数，给它们命名，然后用 list 或 dict 里的名称来引用它们就会让你受不了。但是，在那种情况下，lambda 表达式是足够简单的，如果你有一些异常，在 list 或 dict 之前使用 def 才是一种好的妥协。
PyPy
由 Btrot69 提问：“你觉得 PyPy 代表未来的发展方向吗？你是否对此表示怀疑？如果是，为什么？”
Guido：我对此仍然持怀疑态度，有两个原因：（1）它们还不支持 Python3。（2）还有很多扩展模块不能很好的支持。但是我希望它们能修复那些问题。作为 PyPy 项目的竞争者，Jython 和 IronPython 会让 CPython 项目保持其发展势头。
浏览器运行 Python？
多年以来，曾经尝试几次创建一个沙箱版本的 Python，使之能够运行在浏览器上。主要是因为 Javascript 的问题。而现在针对 Javascript 做的工作，我们有了一个很好的替代品 CoffeeScript——那现在是不是已经是时候来实现让 Python 运行在浏览器里的功能了？
Guido：我在 1995 年就放弃了这件事。并且请不要把 Python 编译成 Javascript。它们的语义非常不同，结果是你用 Javascript 写了一个 Python 运行时，它会让运行变得太慢。
Python3
由 MetalliQaZ 提问：“你对目前向 Python 3 的迁移的迁移感觉怎么样？从一个用户的角度来看，一些流行的库的转变还差得很远，而这阻碍着这种过渡。在我的专业所及的地方，基本上我用的所有系统都没有 安装 3.x 解释器。事实上，2.7 也很少，我想听听你的看法。”
Guido：很好奇你在哪工作。我同意向 Python3 的迁移会持续很长时间，但是如果你的系统还没用上 2.7 版本的话，那就真是有点古老了！在我离开 Google 的时候，所有向 Python2.7 过渡的工作全部完成了（在前几年已经成功的从 2.4 迁移到 2.6），在 Dropbox 这里，客户端和服务器端都是用的 2.7。这两个公司都在考虑 Python3 的问题了。
再来说向 Python3 的迁移，我实际上是相当乐观的。很多流行的库都开始着手做这件事。它确实会持续很长时间，但也有很多进展，过几年之后，我希望所有的代码都能迁移到 Python3 上来。完全根除 Python2 的使用可能会花更多的时间，但是呢，Windows XP 不也是没完全死掉吗。
英文原文： Interviews: Guido van Rossum Answers Your Questions