《Python 程式設計》（第二版）序言

不到五年前，我為《Python 程式設計》第一版寫了序言。自那時起，這本書的變化與語言和 Python 社群的變化幾乎一樣大！我不再覺得有必要為 Python 辯護：Mark 的序言中列出的統計資料和發展足以說明一切。

在過去的一年中，Python 取得了長足的進步。我們釋出了 Python 2.0，這是一個巨大的進步，它具有新的標準庫功能，如 Unicode 和 XML 支援，以及一些新的語法結構，包括增強的賦值：您現在可以寫 x += 1 而不是 x = x+1。有些人想知道這有什麼大不了的（答案：與其使用 x，不如想象 dict[key] 或 list[index]），但總的來說，這對於那些已經習慣在其他語言中使用增強賦值的使用者來說是一個巨大的成功。

不太受歡迎的是擴充套件的 print 語句：print>>file，它是列印到與標準輸出不同的檔案物件的快捷方式。就我個人而言，這是我最常用的 Python 2.0 功能，但大多數對此發表意見的人都認為它是一種令人憎惡的東西。新聞組上關於斥責這個簡單語言擴充套件的討論帖子是有史以來最長的帖子之一——除了永無止境的 Python vs. Perl 的討論之外。

這引出了下一個話題。（不，不是 Python vs. Perl。在序言中挑起爭端不是一個好地方。）我的意思是 Python 進化的速度，這是本書作者非常關心的話題。每當我向 Python 新增一個功能時，Mark 的頭髮就會多出一撮灰色：又有一個章節過時了！特別是新增到 Python 2.0 的大量新功能，在他編寫第二版的時候出現，這讓他擔心：如果 Python 2.1 添加了許多新的東西怎麼辦？這本書一旦出版就會過時！

放鬆，Mark。Python 將繼續發展，但我保證我不會刪除正在使用的東西！例如，關於 string 模組有很多擔憂。現在字串物件有了方法，string 模組大多是多餘的了。我希望我能宣告它已過時（或已棄用），以鼓勵 Python 程式設計師開始使用字串方法。但鑑於大量現有 Python 程式碼（甚至許多標準庫模組）匯入了 string 模組，這種更改顯然不會在一夜之間發生。刪除 string 模組的第一個可能的機會將是在引入 Python 3000 時；即使那時，為了與舊程式碼一起使用，向後相容庫中可能仍然會有一個 string 模組。

Python 3000？！是的，這是下一代 Python 直譯器的暱稱。這個名稱可以被認為是 Windows 2000 的雙關語，或者是指神秘科學劇院 3000，這是一個具有狂熱追隨者的非常 Python 式的電視節目。Python 3000 何時釋出？不會在很長一段時間內——儘管您不必等到 3000 年。

最初，Python 3000 旨在對該語言進行完整的重寫和重新設計。這將使我能夠進行不相容的更改，以便修復在向後相容的方式中無法解決的語言設計問題。然而，目前的計劃是將必要的更改逐步引入當前的 Python 2.x 開發線，並提供清晰的過渡路徑，包括一段時間的向後相容性支援。

例如整數除法。與 C 一樣，Python 當前將具有兩個整數引數的 x/y 定義為具有整數結果。換句話說，1/2 產生 0！雖然大多數頑固的程式設計師都期望這樣，但對於新手來說，這仍然是一個持續的困惑之源，而新手在不斷增長的 Python 使用者群體中所佔的比例越來越大。從數值角度來看，對於 / 運算子，無論運算元的型別如何，都產生相同的值確實更有意義：畢竟，這是所有其他數值運算子所做的。但是我們不能簡單地更改 Python，使 1/2 產生 0.5，因為（就像刪除 string 模組一樣）它會破壞太多現有程式碼。該怎麼辦？

該解決方案過於複雜，無法在此處詳細描述，它將跨越多個 Python 版本，並且需要逐步增加 Python 程式設計師的壓力（首先透過文件，然後透過棄用警告，最終透過錯誤）來更改其程式碼。順便說一下，用於發出警告的框架將作為 Python 2.1 的一部分引入。抱歉，Mark！

因此，不要期望很快宣佈釋出 Python 3000。相反，有一天您可能會發現您已經在使用 Python 3000 了——只是它不會被稱為 Python 3000，而是類似 Python 2.8.7 之類的東西。您在這本書中學到的大部分內容仍然適用！儘管如此，在過渡時期，對 Python 3000 的引用將比比皆是；要知道這在最純粹的意義上是有意為之的。與其擔心 Python 3000，不如繼續使用並學習更多關於您擁有的 Python 版本。

我想談談 Python 當前的開發模式。直到 2000 年初，Python 有數百名貢獻者，但基本上所有貢獻都必須透過我的收件箱。要提出對 Python 的更改，您需要給我傳送一個上下文差異，我會將其應用到我的 Python 工作版本中，如果我喜歡它，我會將其簽入到我的 CVS 原始碼樹中。（CVS 是一個原始碼版本管理系統，也是幾本書的主題。）錯誤報告遵循相同的路徑，只是我也最終不得不提出補丁。顯然，隨著貢獻數量的增加，我的收件箱成為了瓶頸。該怎麼辦？

幸運的是，Python 並不是唯一有此問題的開源專案，VA Linux 的一些聰明人提出了一個解決方案：SourceForge！這是一個動態網站，提供一整套分散式專案管理工具：一個公共 CVS 儲存庫、郵件列表（使用 Mailman，一個非常流行的 Python 應用程式！）、討論論壇、錯誤和補丁管理器以及下載區域，所有這些都可供任何開源專案按要求使用。

我們目前有一個擁有 30 名志願者的 SourceForge 簽入許可權的開發組，以及一個由兩倍人陣列成的開發郵件列表。有特權的志願者都已宣誓效忠 BDFL（終身仁慈獨裁者——那就是我 :-)。透過一個輕量級的提案和反饋系統——Python 增強提案 (PEP) 來管理主要新功能的引入。我們的 PEP 系統非常成功，以至於當 Tcl 社群從教堂模式過渡到集市模式時幾乎逐字複製了它。

因此，我對 Python 的未來充滿信心，現在我將舞臺交給 Mark Lutz。幹得好，Mark。最後用我最喜歡的 Monty Python 引言結束：交給指揮家 Eric！

Guido van Rossum
弗吉尼亞州雷斯頓，2001 年 1 月