|
據(jù)我了解，現(xiàn)在可以下載并運行四種 Python 的實現(xiàn)，還有一種實現(xiàn)正在創(chuàng)建中。每種實現(xiàn)都有其存在的特殊理由，這些理由可以在這里從實現(xiàn)開發(fā)者自己的話語里了解到。 對不同的平臺重新編譯編譯器或解釋器所產(chǎn)生的實現(xiàn)只是略有不同（可能有少量的條件性編譯和更改），但最有趣的實現(xiàn)（就我而言）是超越平臺問題的那些。實際上，我們在這篇文章中將要看到的那些 Python 實現(xiàn)大多本身就是多平臺。實現(xiàn)的概念也與 版本的概念有所區(qū)別。就語言特性而言，這里談到的所有實現(xiàn)基本上都處于同一語言版本 (1.5.2)。很明顯，CPython 1.6/2.0/3000 已經(jīng)有一個部分屬于新的基本實現(xiàn)，但其它實現(xiàn)可以同樣地與那些語言級別的特性一致。 重新實現(xiàn)了哪些編程語言，實現(xiàn)的頻率怎樣，出于什么原因，以及由誰實現(xiàn)？要形容這組語言非常困難。某些與 Python 幾乎處同一地位的流行語言 -- 例如 perl、REBOL 和 PHP -- 只有一種實現(xiàn)（編譯成許多平臺）。TCL 與 Perl/PHP 最為相似，但 確實有一種稱為 Jacl 的 Java 平臺版本。從另一個極端來看，例如 C、Awk、Cobol、REXX 和 Java 這樣的語言，每個都曾經(jīng)被無數(shù)次地實現(xiàn)。但那些再實現(xiàn)是為了許可和營銷等考慮，而不是出于實現(xiàn)的概念和抽象問題。似乎有特殊學(xué)術(shù)意味的那些語言重新實現(xiàn)得很多（特別是函數(shù)性、邏輯性或超純 OOP 語言，例如Smalltalk 和 Eiffel）。Lisp 沒有幾百個也有幾十個實現(xiàn)和派生。 與我們將要討論的 Python 實現(xiàn)不同，Lisp 的派生在提供新實現(xiàn)的同時往往引入許多新穎的 語言特性。Python 實現(xiàn)在很大程度上實現(xiàn)和主要 CPython 版本 相同的 Python 語言。所有現(xiàn)有的版本都是開放源碼合作努力的結(jié)果，這種情況下，創(chuàng)新與市場定位沒有太大關(guān)系，甚至與有時導(dǎo)致開放源碼項目分裂的許可證爭斗也沒有什么關(guān)系。而且，不同的 Python 版本也不是真正傳統(tǒng)意義上的 支流，而集中于不同的概念，正是這些概念證明它本身就是 Python 實現(xiàn)。 兩種沒有詳細(xì)說明的實現(xiàn)是 JPython 和 Python.NET。JPython 是以 Java 編寫的編譯器，用于將 Python 源代碼編譯成 Java 字節(jié)碼。Python 應(yīng)用程序最終是在 JVM（用戶可能不知道它是以 Python 源代碼而不是 Java 編寫的，他們也不需要關(guān)心）中運行的。Python.NET 是個還未交付的實現(xiàn)，但它 -- 至少在結(jié)構(gòu)上 -- 將與 JPython 相似。Python.NET 將讓 Python 參與到微軟的 .NET 項目中，該項目基本上接近于一個可以運行以各種語言（例如新的 C#、Visual、Basic、C++，以及 Python）編寫的程序的非 Java VM。請隨時關(guān)注這些實現(xiàn)的開發(fā)者發(fā)布的信息。 有兩種從理論角度上講使人著迷的實現(xiàn)，下面，就讓我們聽聽它們的開發(fā)者都說了些什么：開發(fā) Vyper的 John Max Skaller 和開發(fā) Stackless Python的 Christian Tismer。 Vyper：采訪創(chuàng)始人 John Max SkallerVyper 是以函數(shù)性語言 Ocaml (3.00) 編寫的 Python 語言的實現(xiàn)。與其它 Python 實現(xiàn)比較，Vyper 提供了一些（可選的）語言擴(kuò)展：更強(qiáng)大的范圍確定規(guī)則和一些新的函數(shù)性特性。Vyper 現(xiàn)在不再進(jìn)行開發(fā)，但它以后可能得到增強(qiáng)（請參閱 參考資料獲得 Vyper，以及它的源代碼。）。我問 Vyper 的創(chuàng)始人 John Max Skaller 有關(guān)建造 Vyper 的動機(jī)。 Skaller：建造 Vyper 有兩個原因：首先，我喜歡 Python，特別是它的簡單性。但我不喜歡它缺乏范圍確定性，凡事都需要做大量更改來取得進(jìn)展。因此我決定在保留與 Python 兼容性的同時，通過建造高級得多的編程語言，并在其中建造函數(shù)性編程語言的某些概念來改正這些問題。 第二個原因是性能。我有一個稱之為 interscript 的主要 Python 程序，一個有讀寫能力的編程 (LP) 工具，它不僅受到 Python 中缺乏良好結(jié)構(gòu)（如上所述），而且還受性能問題的困擾。 Mertz：既然文字編程是創(chuàng)建 Vyper 的一個動機(jī)，您是否能簡單介紹一下什么是有讀寫能力的編程，我想這樣對讀者會有所幫助。 Skaller：它的構(gòu)思是不需要為程序記錄文檔（在編程后），而是編寫 包含程序的文檔。[它]由 Donald Knuth 發(fā)明。 interscript 獨立于排字和編程語言，可以通過以 Python 編寫的任意可執(zhí)行代碼 在文檔中擴(kuò)展。即，盡管有大量預(yù)構(gòu)建的構(gòu)造可以滿足“日?！毙枰粋€人可以隨意 生成代碼和文檔。 但除非 LP 很快，否則它永遠(yuǎn)不能作為主流技術(shù)接納。我花費了許多工作使它變得快一些，但結(jié)果，Python 還是無法快到執(zhí)行所需要的操作：解釋語言中逐個字符地處理字符串就是無法快起來。 所以想要構(gòu)建一個 Python 編譯器，至少它能生成可以優(yōu)化這種代碼的機(jī)器二進(jìn)制文件。這是某些 Vyper 擴(kuò)展的一個原因，從而使優(yōu)化成為可能。
我從來沒有編寫過編譯器；構(gòu)思是編寫一個解釋器，可以在編譯時裝入所有程序模塊，然后將產(chǎn)生的字典
Mertz：Vyper 的一個特別新穎的特性是其以 Ocaml 的實現(xiàn)。許多讀者可能認(rèn)為編譯器／解釋器是以 C 實現(xiàn)的（與本質(zhì)接近）；或者對于已定義的機(jī)器，編譯器可以以 Python 自身實現(xiàn)。為什么使用 Ocaml？ Skaller：Ocaml 直接生成機(jī)器代碼。相對于 C 來說，它運行得相當(dāng)不錯，對于某些工作甚至?xí)?。它還帶有一個無用信息收集器。Ocaml 是一種高級語言，與 C、C++、Python 或大多數(shù)其它所謂的“高級”語言不一樣。 Ocaml 和 Python 一樣，是混合的函數(shù)性／命令語言。Vyper 比 Python 更多地強(qiáng)調(diào) Python 的函數(shù)性方面。它糾正了一些明顯的設(shè)計缺陷，特別是缺少詞法范圍確定的問題。 在實際中，函數(shù)性編程后面有強(qiáng)大的理論支持，而對于命令編程則沒有任何理論支持。這意味著從開發(fā)角度來說，函數(shù)性編程語言比任何命令編程語言通常要好得多，但往往缺乏與基本硬件規(guī)則體系結(jié)構(gòu)相近的系統(tǒng)性能。 有意思的是，下一種實現(xiàn)，盡管來自不同角度，在某些方面要勝過 Vyper： Skaller：該項目的另一致命“殺手”是 Stackless Python。它執(zhí)行的某些任務(wù)是我當(dāng)前使用的編譯器所執(zhí)行的任務(wù)，而這些是 Vyper 可能永遠(yuǎn)都做不到：它使“超輕量型線程”（由事件調(diào)度器驅(qū)動的合作多任務(wù)）的實現(xiàn)成為可能。 Vyper 是以 Ocaml 實現(xiàn)的，而后者使用機(jī)器堆棧；必須避免它，因為堆棧切換（用于同時從一個服務(wù)器處理許多客戶機(jī)）非常昂貴。 Stackless Python：采訪創(chuàng)始人 Christian Tismer第一次見到 Stackless Python 時，它象是 CPython 的一個小支流。談到編碼，Stackless 對實際的 Python C 代碼只做了小小更改（并重新定義“事實”）。不過，Christian Tismer（ Stackless Python 的創(chuàng)始人）在 Stackless 中引入的概念非常深奧。它是“延續(xù)性”的概念（并且以 Python 對他們編程的方法）。 要嘗試用最簡單的術(shù)語解釋它，延續(xù)性就是一種表示法，在程序中的特定點上，程序的每樣事物都可以連續(xù)執(zhí)行。延續(xù)性是依賴于初始條件的潛在。不是以傳統(tǒng)方式進(jìn)行循環(huán)，它可能使用不同的初始條件遞歸調(diào)用相同的持續(xù)性。我看到過的一種概括說法是，從理論上說，延續(xù)性更基本并位于 每個其它控制結(jié)構(gòu)下。如果這些想法把您搞糊涂了，不必?fù)?dān)心；這是正常的反應(yīng)。 閱讀 參考資料中 Tismer 的背景文章是進(jìn)一步理解的良好開端。最好在閱讀該文章后繼續(xù)閱讀他的參考資料。但對目前來說，讓我們在更一般的級別上與 Tismer 進(jìn)行交談： Mertz：Stackless Python 確切來說是什么？有什么初學(xué)者可以理解的概念能夠解釋有關(guān) Stackless 的不同之處？ Tismer：Stackless Python 是一種不在 C 堆棧上保存狀態(tài)的 Python 實現(xiàn)。它的確有堆棧 -- 要多少有多少 -- 但這些是 Python 堆棧。 C 堆棧不能從例如 C 這樣的語言以干凈的方式進(jìn)行修改，除非以預(yù)期的順序進(jìn)行。它對您施加了很大限制：您必須回到這里，與您離開的方向正好相反。 “普通的”程序員一開始不會認(rèn)為這是個限制。他們必須從開始就要學(xué)會將想法轉(zhuǎn)向堆棧。堆棧沒有什么壞處，并且通常它們施加的執(zhí)行順序就是實際上的順序，但這并不意味著我們必須等待一個這樣的堆棧序列完成才能運行另一序列。 程序員在必須執(zhí)行非阻塞調(diào)用和回調(diào)時意識到這一點。堆棧突然擋住去路，我們必須使用線程，或?qū)顟B(tài)明確存儲在對象中，或者構(gòu)建顯式的可切換堆棧等等。Stackless 的目的是幫助程序員避免這些問題。 Mertz：Stackless 的目標(biāo)是達(dá)到與 CPython 100% 二進(jìn)制兼容。是嗎？ Tismer：Stackless 此刻就是 100% 的二進(jìn)制兼容。這意味著：安裝了 Python 1.5.2 后，用我的 Python15.dll 替換，每個文件仍能工作，包括每個擴(kuò)展模塊。這不是目標(biāo)，而是要求，因為我不希望關(guān)注所有擴(kuò)展。 Mertz：我認(rèn)為 Stackless Python 絕對能吸引人們對它加以了解。和大多數(shù)講實際的程序員一樣，我在完全理解它時遇到了難題，但這是使它顯得特別有趣的一部分。 Tismer：是啊，我也很講實際，您可以想象在沒有任何持續(xù)性概念，并且不知道在 Python 中它到底是什么樣的情況下實現(xiàn)這樣一件東西有多困難。無法想象某些事物，但要投入去做是我最大的挑戰(zhàn)。完成后就很容易想象，也很容易重新設(shè)計。但在六個月的全職工作中，我猜有五個月的時間是在凝視屏幕和敲打鍵盤。 延續(xù)性很難銷售。協(xié)同程序和生成器，特別是微線程還稍容易一點。所有以上產(chǎn)品都 可以在沒有顯式持續(xù)性的情況下實現(xiàn)。但有了持續(xù)性后，會發(fā)現(xiàn)轉(zhuǎn)向其它結(jié)構(gòu)所花費的步驟非常少，持續(xù)性就是使用的方法。所以我要改變我的營銷策略，不再嘗試銷售持續(xù)性，而是它們的成果。對于能夠看到光明的人來說，持續(xù)性仍然存在。 Mertz：有一個關(guān)于美國工程師和法國工程師的笑話。美國小組給法國小組帶來一個原型。法國小組的反應(yīng)是：“它在實踐中工作得不錯；但在理論上靠得住嗎？”我想這個笑話可能是要嘲弄一下“法國人”的作風(fēng)，但在我自己看來，我完全認(rèn)同“法國人”的反應(yīng)。排除笑話中任何針對特定民族的刻板模式，對它的認(rèn)同是吸引我去了解 Stackless 的原因。CPython 在實踐中使用，而 Stackless 在理論中使用?。〒Q句話說，對于我個人，持續(xù)性的抽象純粹性比微線程的上下文切換加速更有趣）。 Tismer：我也有類似的感覺。認(rèn)識到 CPython 可以在不涉及 C 堆棧的情況下實現(xiàn)后，我確信它 必須用這種方式實現(xiàn)；其它所有方法都很荒唐。CPython 已經(jīng)為框架對象付出了代價，但它使用 C 堆棧嘗試它們更是喪失了所有自由。我覺得我必須解放 Python。:-) 我 1999 年 5 月開始這個項目。Sam Rushing 曾對硬件協(xié)同程序的實現(xiàn)有過粗略的研究，所以一場有關(guān) Python 設(shè)備的討論開始了。將堆棧復(fù)制做大量更改永遠(yuǎn)也不能將它變成 Python，這一點當(dāng)時就很清楚。但可移植的、干凈實現(xiàn)的協(xié)同程序可能可以。不幸的是，這是不可能的。五年前，Steve Majewski 在意識到如果不完全重寫 Python 就無法解決這個問題之后就放棄了。 那就是挑戰(zhàn)所在。我必須查明它。它如果是可能的，我就實現(xiàn)它；如果不可能，我就要證明這種不可能性。不久以后，經(jīng)過了首次考慮和嘗試后，Sam 告訴我有關(guān) call/cc 以及它是如何強(qiáng)大。那時，我對它們在哪些方面比協(xié)同程序更強(qiáng)大一點概念也沒有，但我相信他并實現(xiàn)了它們；六七次以后，總要完全重寫，使我有了更深入的理解。 我希望最終能夠以令人眼花繚亂的高速度創(chuàng)建線程，但我的初衷是發(fā)現(xiàn)究竟我能到達(dá)什么地步。 Mertz：在實踐方面，Stackless 可能有哪些性能改進(jìn)呢？這些改進(jìn)在當(dāng)前的實現(xiàn)中有多重要？它還有多少潛力可挖？哪些特定類型的應(yīng)用程序最有可能從 Stackless 中受益？ Tismer：在當(dāng)前的實現(xiàn)中，Stackless 比傳統(tǒng)調(diào)用方案來說并不占太大的優(yōu)勢。普通的 Python 對新解釋器開始遞歸。Stackless 展開到一個調(diào)度器，然后從那里啟動解釋器。這點幾乎一樣。實際的改進(jìn)在于協(xié)同程序和線程的實現(xiàn)。它們需要由類模擬，或者需要是標(biāo)準(zhǔn) Python 中的實際線程，但使用 Stackless，它們可以更直接地實現(xiàn)。 如果不對操作碼集做巨大的更改，核心的更多改進(jìn)就顯得不太可能。但一個具有對其它地方延續(xù)性更多內(nèi)置支持的再實現(xiàn)可以大大提高速度。 受益最大的那些特定應(yīng)用程序可能是 Swarm 仿真，或有許多角色扮演極小任務(wù)的多人游戲。一例就是正在使用 Stackless Python 開發(fā)的 EVE 游戲（請參閱下面的 參考資料）。 Mertz：對于將 Stackless 合并到 CPython 主流您覺得如何？Stackless 是作為一個分支好呢，還是成為核心版本的話有些方面會更好？ Tismer：有一些支持和反對的爭論。反對：只要我不放棄 Stackless 實現(xiàn)，它就是我的，我不需要討論如何以及為什么的問題。但同時，我在盡力（但未能）追趕 CVS。最好讓其它人來做。 其它不必對稀奇古怪的事物感興趣的那些 Python 用戶根本不會認(rèn)識 Stackless；只是事實上它碰巧更快，最大遞歸級別現(xiàn)在是一個選項而不是硬件限制。對每個用戶還有另一個保證：將有可腌制 (pickleable) 執(zhí)行狀態(tài)。這意味著可以在程序運行的時侯保存它，將它發(fā)送給朋友，然后繼續(xù)運行。 最后，假使我的所有東西都變成核心，我就完全贊成；但我不希望看到一個就好象建議過多次的不完整的解決方案。 Mertz：對 Stackless 的未來方向有什么想法嗎？將生產(chǎn)什么新的不同產(chǎn)品？Stackless 仍然受一些遞歸的困擾。它們會消失嗎？ Tismer：將部分地實現(xiàn)腌制支持。首先對于微線程使用，因為現(xiàn)在它們提供最干凈的概念。它們在“潔凈室”里生活，這里不存在余下的遞歸問題。我的最終目標(biāo)是從 Python 中除去 全部解釋器遞歸。Stackless 的某些部分仍舊有遞Stackless Python：采訪創(chuàng)始人 Christian Tismer定義的 __xxx__ 方法。要定案很難，因為我們需要更改很多東西、添加新的操作碼、展開某些內(nèi)部調(diào)用序列等等。 參考資料
|
|
|
