標籤：

Python的設計理念與簡要年譜

04-18

本系列文章譯自Python之父 Guido van Rossum 的系列博客「The History of Python」。這個博客系列對我們理解Python及其演變很有幫助，在這裡翻譯推薦給大家，希望大家喜歡，也請大家多多指教！

1. 基本原則

之後的博文將專註於 Python 歷史中的一些細節。不過，在此之前，我想先闡述一下我在 Python 的設計和實踐中所遵循的一些基本理念。

首先，Python 一開始只是一個個人實驗性項目，沒有任何官方背景，因此我必須儘快取得成果，某種程度上也是為了爭取管理層的支持（這點我倒是做得還不錯）。這使我採取了一些節約時間的原則：

  1. - 借鑒任何有道理的想法。
  2. - 「儘可能簡單，而不是相對簡單。」（愛因斯坦）
  3. - 只做一件事並把它做好（UNIX哲學）。
  4. - 不必太擔心性能——必要時再來優化。
  5. - 跟隨潮流，不與大環境作對。
  6. - 別追求完美，往往「足夠好」就是完美。
  7. - （由上一條）有時可以抄近道，尤其在你之後能改正的情況下。

而其它一些原則則不為節約時間，有時還恰恰相反：

  1. - Python 不能被某個平台所綁定。有些功能在一些平台上沒法用可以接受，但核心功能必須跨平台。
  2. - 機器能處理的，就不能勞煩用戶。（正如之後將提到的，事實上我並沒有完全遵循這條原則，並因此導致了一些災難性後果）
  3. - 支持並鼓勵用戶寫出跨平台的代碼，但也不拒絕某個平台的特有能力或資源。（這一點與Java形成鮮明對比）
  4. - 一個大型複雜系統，應該在不同層級都支持擴展。從而不論是老手還是新手，都能儘可能地發揮自主性。
  5. - 不能有致命錯誤。也就是說，只要虛擬機正常工作，用戶代碼應該在碰到錯誤後能恢復運行。
  6. - 同時，錯誤不應該被忽視。（很自然地，本條與上條原則決定了 Python 使用 exceptions 來處理錯誤）
  7. - 用戶代碼中的 bug 不允許產生 Python 解釋器的未定義行為，不能因用戶錯誤導致內核崩潰。

另外，關於什麼是好的編程語言設計，我也有不少想法——主要來自於 ABC 語言團隊，也是在這個團隊中，我第一次獲得了編程語言設計與實踐的實際經驗（譯註：作者在這個團隊工作了幾年）。不過這些想法很難用文字表達，因為每個人對優雅、簡潔與可讀性的理解是比較主觀的。

雖然之後我也會討論到 ABC 語言對 Python 的影響，但這裡還是要提到一條關於可讀性的原則：與日常寫作或高等數學相比，Python 中應減少標點符號的使用。我們會使用一些編程語言中的傳統符號，比如 「x * y」表示相乘，「a[i]」表示列表切片，或者「x.foo」表示對象屬性等，但 Python 不會用「$」表示變數，也不會用「!」表示特殊操作。

2. Python之禪

Tim Peters，一位忠實的 Python 程序員，後來也成為持續高產的 Python 核心開發者，曾把我未表達的設計原則總結為他所謂的「Python 之禪」，這裡我全文引用如下：

美比丑好；

詳盡比模糊好；

簡單比複雜好；

複雜比繁複好；

扁平比嵌套好；

疏鬆比密集好；

可讀性很重要；

雖然實用比純粹好，但特例不能破壞原則；

錯誤不應被忽略，除非有意為之；

如有歧義，拒絕猜測，總有一種——最好是只有一種——沒有歧義的解決方案，

雖然這種方案可能一開始並不明顯——除非你是 Python 之父；

現在就做比永遠不做好，雖然有時，永遠不做要比胡做一通好；

如果你的代碼難以解釋，說明它很爛；

如果你的代碼容易理解，則可能是好代碼；

命名空間是個好東西——我們得多加應用！

3. 有意避免的觀念

雖然我在 ABC 語言的經驗對 Python 有很大的影響，但有些地方，它們也採用了完全不同的原則。以下是 Python 有意避免的一些觀念：

  1. ABC 語言團隊儘力追求完美。比如說，其採用的樹狀數據結構在處理大型數據集合時效率更高（不過在處理小型數據集合時並不明顯）。
  2. ABC 語言希望構建一個儘可能獨立於外在生態的系統。不僅數字範圍、字元串長度、集合規模沒有限制（除非超出系統內存），而且用戶也不必關心文件、磁碟、「保存」動作或其它應用程序。ABC 語言希望自己能滿足用戶的所有需求，這也使 ABC 語言團隊寫了一套完整的，只適用於 ABC 語言的集成編程環境（當然，你要不想用也不是不行，但這一般不是第一選擇，而且 ABC 語言不直接支持其它環境）。
  3. ABC 語言團隊假設所有用戶都沒有電腦經驗（或者願意拋開之前的經驗）。因此，很多術語都用非常「新手」的替代詞，比如用「做法（how-tos）」替代「過程（procedures）」，用「地址（locations）」替代「變數（variables）」等。
  4. ABC 語言團隊在設計時並沒有一個預定的演化路徑，也不打算讓用戶參與到語言的設計中來。ABC 語言一開始就是一個封閉的系統，設計者們希望儘可能地把它設計得完美一些，它不鼓勵用戶關心語言背後的事。雖然有過向高級開發者開放部分源碼的討論，但始終沒有實現。

某種意義上說，我在設計 Python 時所採用的設計哲學，或許是其最終取得成功的主要原因之一。它並不在一開始就追求完美，但足夠滿足大家的需求，隨著用戶越來越多，許多改進建議被納入其中。正如大家將在之後的博文中看到的，許多建議都涉及 Python 核心部分的重大改變或重構。直到如今，Python 依然在持續演化之中。

4. 簡要年譜

我開發 Python 的時候，也正是其它動態（而且開源）編程語言開始活躍，並越來越受歡迎的時代，比如 Tcl、Perl、以及（後來的）Ruby。為把 Python 置於一種歷史視角之下，我將 Python 的版本發布記錄羅列如下，因為我也沒記錄當時的所有事情，所以早期的時間比較寬泛：

發布日期 版本號

- 1989.12 開始開發

- 1990 在 CWI 發布內部版本

- 1991.02.20 0.9.0（發布在 alt.sources）

- 1991.02 0.9.1

- 1991.08 0.9.2

- 1991.12.24 0.9.4

- 1992.01.02 0.9.5（只支持蘋果系統）

- 1992.04.06 0.9.6

- 1992年某天 0.9.7beta

- 1993.01.09 0.9.8

- 1993.07.29 0.9.9

- 1994.01.26 1.0.0

- 1994.02.15 1.0.2

- 1994.05.04 1.0.3

- 1994.07.14 1.0.4

- 1994.10.11 1.1

- 1994.11.10 1.1.1

- 1995.04.13 1.2

- 1995.10.13 1.3

- 1996.10.25 1.4

- 1998.01.03 1.5

- 1998.10.31 1.5.1

- 1999.04.13 1.5.2

- 2000.09.05 1.6

- 2000.10.16 2.0

- 2001.02.25 1.6.1

- 2001.04.17 2.1

- 2001.12.21 2.2

- 2003.07.29 2.3

- 2004.11.30 2.4

- 2006.09.16 2.5

- 2008.10.01 2.6

- 2008.12.03 3.0

我給 python.org 上還推薦的版本加了鏈接（譯註：現在都是古老的版本了）。有些小版本並不在上面的列表中，比如 2.0.1 等，否則這個列表就太長了。你依然可以在 python.org/ftp/python/s 上找到各版本的源代碼。

個人公眾號：讀書錄

推薦閱讀：

TAG:Python | Python入門 | Python開發 |