python 創始人訪談錄2: python 的起源，特點和未來

主持人: 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 的最大缺點大概就是它是由我發明的

 

 

http://blog.csdn.net/koalant/archive/2007/05/14/1607902.aspx