转载自: http://www.javaeye.com
听译这东西的确很累人，一次翻译太多也很疲惫。 我尽量想在一篇博客中包含尽量多的内容，结果最终搞的自己兴趣全无了，下次看来还是应该一点一点的来。 我的听力还是不好，有一些东西没听出来我就不翻译了，大体意思上应该不会差很多的，希望大家见谅。
主持人: Chris DiBona （Google 开源网站负责人） and Leo Laporte （Twit 网站创始人）
被采访人：
Guido van Rossum （python 创始人）
Chris DiBona: 非常高兴 Guido 让我为这次采访做安排
Leo Laporte: 我们这里需要说明一下，Guido van Rossum 十六年前创建 python 语言，他现在在 google 工作。
Chris DiBona 是的，他已经在那里工作了一段时间了。
Leo Laporte: Google 是 python 的一个大用户。首先，我要问一个问题，guido , 是关于 python
起源的，如果我说错了，请你更正一下。就我所知，最初 python 的设计是为了教学的目的，你想创建一个用于学习和编程的语言，这么说对吗？
Guido van Rossum: 恩，很多人都这么认为，这个问题问的好，因为它让我可以追溯一下 python 的背景。python
从一个叫 ABC 的语言继承了很多东西，而 ABC 这种语言在设计的时候就特别考虑到用于教学。那是在上世纪七十年代晚期和八十年代早期，我在
abc
语言的实现小组，在那里我融入到语言设计讨论，语言实现，脑力激荡中，相当的令人兴奋。在八十年代末期，８９年的时候，我觉得自己有必要创建一门新语言，
我借鉴了 abc
语言中我所喜欢的特点，并将其中我不喜欢的东西用自己创新的或一些借鉴自别处的想法取而代之。我的目标要要建立一个为专业程序员使用的脚本语言，而这些专
业程序员主要使用 C 语言和 borne shell 脚本语言作为他们的主要开发语言。 python 的位置大概是介于 C 和 Shell
语言二者之间的，所以我创建 python 并没有明确的教学目的.
Leo Laporte: 这很有趣
Guido van Rossum: 因为我从ABC语言中借鉴了那么多，而 abc 本身又有教学的目的在其中，所以我建立的语言也就很适合做教学语言。
Leo Laporte: 人们问我很多次，每次我都向他们推荐 python 。 因为它是免费的，而且是跨平台的。它的解释器，使用它来教学编程很简单，你可以立刻尝试用解释器来学习语言。
Guido van Rossum: 没错，这是我从ABC 借鉴来的，ABC 也具有这些特点。
Chris DiBona 那么 ABC 是不是也有严格的空白格式要求吗？
Guido van Rossum: ABC 也有强制缩进的要求。
Leo Laporte: 我想这也是很多人一直抱怨的地方，我并不在意这个。你是否意识到这个问题？
Guido van Rossum: 我并不确定你说的这个一直是个问题，我也不认同你说的有这种抱怨。大多数情况下，这是人们自己不打算学习 python 所采用的一种很方便的借口。如果人们忽略这点，会发现这种缩进要求是愉悦的。
Leo Laporte: 你能写出优美的源码，而且很容易书写。你为什么这么设计。
Guido van Rossum: 这点我是借鉴自 ABC 的，而且我非常喜欢这个特点。他们这么设计可能是出于创新，他们有很多
algo 和algo 60 语言风格的经验， begin , end 语句
相当的麻烦，当缩进并不和程序结构相匹配，光靠关键字也会导致各种理解上的错误，
Chris DiBona begin begin begin end end end.
Guido van Rossum: 是啊，begin 和 end 的个数还可能不相同。
Leo Laporte: 使用空白代替 begin end 的好处在于迫使程序员大量使用缩进，这样可以让程序员看到代码后立刻清楚程序结构。
Guido van Rossum: 在很长的一段时间里，大家都有这么一个认识：任何一个自律的程序员可以任意地使用缩进。这就意味着任何一个人当他看代码的时候，看缩进是为了了解整个程序的结构，而实际上他是在数大括号。
Leo Laporte: 就像 perl 程序员那样，我不该这么说
Chris DiBona 你在挑起战火
Leo Laporte: 我不是要挑起战火，呵呵，我错了，我收回我说的话，我道歉
Guido van Rossum: 这很好。
Chris DiBona 我发现一件事情，无论从项目，公司角度来看，python 都更容易维护，从一个人到另外一个人， 你同意这点吗？
Guido van Rossum: 是啊，我完全同意。这其实不是我专门设计语言的目的，很难说我这么设计的目的。我们印在一些 T
Shirt 上文字实际上是一些玩笑，我们有一个口号，叫做"There is only one way to do
it"(做一件事情只有一个方法)
Leo Laporte: 和 perl 的 "There is moer than one way to do it"(做一件事情有很多种方法)相反
Guido van Rossum: 对，你可能会争论这点，这的确对可维护性很重要。如果做一件事情有很多种方法，如果你把一个任务给两个不同的程序员，他们可能给出两个完全不同的解决方案。
Leo Laporte: 我想程序员喜欢这样吧。
Guido van Rossum: 恩，如果你把一个任务交给两个程序员，他们给出两个解决方案，这也没问题。但是如果 A 程序员在某个时刻要维护 B 程序员的代码，他很可能重写代码而不是维护这段代码，因为这不是 A 程序员选择的解决方案。
Chris DiBona 值得一提的是，有很多很基本的程序计算任务。
Leo Laporte: 是啊，冒泡排序，二分法排序
Chris DiBona 它们太基础了，在这种情况下，显然就不成立了。
Guido van Rossum: 正如我说过的，T Shirt 上印的是一些玩笑。
Chris DiBona 说到 T shirt 的事情，很有趣。比如 Simple is better than complex ，还有其他一些
Guido van Rossum: 我想你说的这个是另外一件 T shirt 上印的口号。 我们有一个称为 Zen of Python 的东西，与其说它是技术信息，还不如说是诗歌。它包含了好几条。
Leo Laporte: 我把 python 当作一个非常优美的语言，它让我联想起来 C ，不过比 C 更清晰，更简单, 有很多库函数支持，开发很高效，运行很快。
Guido van Rossum: 你现在正在学它吗？
Leo Laporte: 是啊，它很容易学习。
Guido van Rossum: 很有趣，你将它和C 比较，实际上它和C 差别很大，你可以说它更象 lisp 而不是 C
Leo Laporte: 但是从表面上看，它看上很象。。。
Guido van Rossum: 对，你说的完全没错，从语法表面上来看，它是很像C ， 我一直在从 C 上借鉴经验，C
语言是我设计python 的参考点之一。我的脑海中一直考虑的是那些和我一样的程序员，用 C 写代码，用 Shell
写代码，这是８０年代程序员的典型程序模块。
Leo Laporte: 我们还是回到 C lisp 的事情，它看上去象 C ,实际上它的底层更象 lisp。 真正的程序员都喜欢 Lisp ，告诉我这是为什么？
Guido van Rossum: Python 和 Lisp 的联系是很有限的，因为尽管 python 内部有很多 lisp
风格的东西，但是在我开始创建 python 的时候，我一点都不懂 lisp, 我现在基本上还是不懂 lisp ，我没有用lisp
写过任何一个，哪怕是很小的项目。
Leo Laporte: 你用 C 写的 python 吧？
Guido van Rossum: 是的， Python 的主要实现是用 C
Leo Laporte: 有 lisp 实现的 python 吗？
Guido van Rossum: 就我所知没有。
Leo Laporte: 肯定有 java 实现吧。
Guido van Rossum: Jython 是用 java 编写，编译为 java 字节码，建立 jython 的那个人实际上最近又建立了 Iron Python 项目，它运行在 .net 上，用 C# 编写。
Leo Laporte: 那么 Python 的 lisp 风格是怎么回事？Python 在结构上是如何解决 lisp 处理的那些问题？
Guido van Rossum: Lisp 和 Python 的主要相似之处在于：任何东西在运行时都是动态的。类似
lisp，python 的分析器，编译器并不清楚程序中发生了什么。 python 的分析器至少知道 if
语句，模块，函数的定义，但是它不知道你在程序中要操作的任何数值的类型。 如果你显示地在python 程序中写了 x + y ，x 和 y
可以是任何类型。你可以在其他语言中做运算符重载，比如 C++ ，编译器总是很清楚地知道 a 和 b 属于那个模块，哪个类，而在python中
，编译器不知道也不在乎这些，他们产生相同的python字节码, 这些字节码可以作用于任何支持 + 加法运算符重载的任何对象。
Guido van Rossum: 它使得你可以以一种探索式的方式编写程序成为可能。你可以在实际开始编程之前不用明确选择类型，类，接口
Chris DiBona 不管类型是否正确
Guido van Rossum: 这样做的好处之一是：如果你写错了，假如你用 Java
写程序，你可能要重构你的项目，改变某些参数的类型，而用 python
，你的代码可能需要的改动会非常少，因为在程序中很多信息并没有明显的声明，也没有那么多的重复。 在java
中你会很多次地声明类型，每个方法都有某些类型的声明，某个参数的声明。 C++ 有同样的问题，C
当然也不例外，基本上静态类型语言都有相同的问题。当你的想法变了，你的程序要修改很多，某个类型到底是什么，它如何工作，怎么被使用，而在python
中，所有的信息都是在运行时中获得的，你只需要改变原始的变量的源头，所有的变化就在程序中自动传递了。
Leo Laporte: 我要好好想想你说的了 (哈哈)， Eric Ramond ６年前写了一篇很有名的文章。他说在开始的时候他不太喜欢 python ,而现在他确信这是他需要的语言，他现在还用 python 编程吗？
Guido van Rossum: 我不知道，这你应该问他，我希望他还在使用 python , 他可能在享受作为一个著名开源倡导者和受人好评的作家的生活。
Leo Laporte: 你呢？ 你现在还在编程吗？
Guido van Rossum: 我总是在编程，我在google 工作，我不做 python 传播工作的时候，我给google
写应用程序服务于 google 的开发团体，我所开发的东西不会触及 google 的用户，而是针对 google 公司自己的工程师。
Leo Laporte: 你还在做 python 进程方面的工作吗？
Guido van Rossum: 现在嘛，我已经尽可能地把大部分python 2
相关的工作委托可信任的人，我很高兴看着他们工作，从来不去干预。我并没有停止开发 python ，我更关注的是下一个
Python版本，我们称之为 python 3000 ，你也可以把它看作 python 3.0
Chris DiBona 是啊， 这个新版本号，呵呵。
Guido van Rossum: 是啊，我们想出这个名字，来源于六年前微软如此激进地宣传自己的 windows ，我想我们可以做的更好一点。
Leo Laporte: 可以比它好1000点，呵呵
Guido van Rossum: 呵呵，这意味着我们不会有发行时间上的问题，这样它就可以稍微迟一些发行。
Chris DiBona 那么 python 3000 是否五年前就考虑的吗？
Guido van Rossum:
不，长期以来它一直是一个神秘的未来版本。最近半年时间里，我做了很多工作让它走上正轨。我写了一些演示，阐明了整个开发过程和python 3000
一些特点，至于发布时间，我希望在明年，也就是07年早期发布一个 alpha 版本，python 3.0 将一年后（2008）可以向广大
python 社区用户发行。但这并不意味着用户需要马上切换到新版本上。因为新旧版本存在不兼容的问题，这也是为什么我们称之为 python
3000 的原因。 这对我是一个机会，可以修正我在90年代早期作为一个程序语言设计新手所犯下的一些设计错误。
Chris DiBona 什么错误？
Guido van Rossum: 恩，时间太短，很难说的很清楚。
我对异常处理的不对，对用户定义类型的设计，整数类型的范围的设计，整数的精度有一些错误，还有一些不太重要的语法上不方便的地方。我们尽可能的修复所有
的错误而不失去向后不兼容性，对不起，是不失去向后兼容性。但是在某些时候，你很难既修复错误又保持向后兼容性。所以，与其在每个新版本， 2.0,
2.3, 2.4, 2.5 中保留一些微小却令人不舒服的不兼容性。 我们选择把这些步骤省下来，就保留一个不兼容的版本， python 3
Leo Laporte: 有些人期待技术上的更新，比如多处理器系统，我知道 python 的多线程支持很好，也许我们应该。。。
Guido van Rossum:
多线程支持并不是我现在打算着手处理的，我把它看作是实现质量上的问题，而不是语言规范的问题。而我们期待和着手处理的是用一个更好方式来支持
unicode, 基本上所有的字符都将是 unicode, 我们将包含一个独立的数据类型代表非字符类型
Chris DiBona 我想 unicode 这方面， java 处理的非常好
Guido van Rossum: 这方面我们当然是借鉴 java 的
Chris DiBona 这真是一个不错的想法
Guido van Rossum: python 在从其他语言上借鉴好想法这一点上是相当开放的，我从来也不羞于承认 python 的哪些特点是从哪里来的，你可以说 python 的最大缺点大概就是它是由我发明的