《Python程式設計》(第2版) 前言

不到五年前，我為《Python程式設計》的第一版寫了前言。從那時起，這本書的改變之大，幾乎與Python語言和社群的變化不相上下！我不再需要為Python辯護：Mark在序言中列出的統計資料和發展情況不言自明。

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

對擴充套件 `print` 語句的熱情就沒有那麼高了：`print >> file`，這是一個列印到不同於標準輸出的檔案物件的快捷方式。就我個人而言，這是我使用最頻繁的Python 2.0特性，但大多數對此發表看法的人都認為它是一個令人憎惡的東西。新聞組上關於這個簡單語言擴充套件的激烈討論是史上最長的討論之一——除了永無止境的Python與Perl之爭。

這讓我想到了下一個話題。(不，不是Python與Perl。與其在前言中挑起爭端，不如去別處。) 我指的是Python進化的速度，這是本書作者心頭的一個話題。每當我給Python新增一個新特性，Mark的頭髮就會多一根白髮：又有一個章節過時了！特別是Python 2.0中新增的大量特性，恰好在他編寫第二版時出現，讓他擔心：如果Python 2.1也新增這麼多新東西怎麼辦？那這本書一齣版就過時了！

放輕鬆，Mark。Python會繼續發展，但我保證我不會刪除仍在積極使用的東西！例如，很多人擔心 `string` 模組。現在 `string` 物件有了方法，`string` 模組在很大程度上是多餘的。我希望我能宣佈它過時（或棄用），以鼓勵Python程式設計師轉而使用字串方法。但考慮到現有的大部分Python程式碼——甚至許多標準庫模組——都匯入了 `string` 模組，這種改變顯然不會一蹴而就。移除 `string` 模組的第一次可能的機會將是在Python 3000的引入時；即便如此，可能在向後相容庫中仍然會有一個 `string` 模組供舊程式碼使用。

Python 3000？！是的，那是下一代Python直譯器的暱稱。這個名字可以被認為是Windows 2000的諧音，或者是對《神秘科學劇場3000》的引用，那是一個擁有狂熱追隨者的、恰如其分的Pythonesque電視節目。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 2.8.7之類的。而且你在這本書中學到的大部分內容仍然適用！儘管如此，與此同時，對Python 3000的引用會隨處可見；你只需要知道這在最純粹的意義上是故意的“概念產品”（vaporware）。與其擔心Python 3000，不如繼續使用和學習你擁有的Python版本。

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

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

我們目前有一個開發小組，擁有SourceForge的簽入許可權，由30名志願者組成，還有一個開發郵件列表，人數是前者的兩倍。這些享有特權的志願者都已宣誓效忠BDFL（終身仁慈獨裁者——那就是我 :-）。新主要特性的引入透過一個輕量級的提案和反饋系統進行管理，即Python增強提案（PEP）。我們的PEP系統非常成功，以至於當Tcl社群進行類似的從“大教堂”到“集市”的轉變時，他們幾乎照搬了我們的系統。

因此，我懷著對Python未來的信心，將發言權交給Mark Lutz。幹得好，Mark。最後用我最喜歡的Monty Python名言來結束：埃裡克，樂隊指揮，你來接手！

吉多·範羅蘇姆
雷斯頓，弗吉尼亞州，2001年1月