Stackless Python 是什麼--做者採訪

     一直沒明白Stackless Python什麼意思，看到這一段3年前對做者的採訪譯文(原文找不到)，稍微有點理解了。但如今Stackless Python感受沒怎麼更新了。

Stackless Python：採訪創始人 Christian Tismer

第一次見到 Stackless Python 時，它象是 CPython 的一個小支流。談到編碼，Stackless 對實際的 Python C 代碼只作了小小更改（並從新定義「事實」）。不過，Christian Tismer（ Stackless Python 的創始人）在 Stackless 中引入的概念很是深奧。它是「延續性」的概念（而且以 Python 對他們編程的方法）。

要嘗試用最簡單的術語解釋它，延續性就是一種表示法，在程序中的特定點上，程序的每樣事物均可以連續執行。延續性是依賴於初始條件的潛在。不是以傳統方式進行循環，它可能使用不一樣的初始條件遞歸調用相同的持續性。我看到過的一種歸納說法是，從理論上說，延續性更基本並位於 每一個其它控制結構下。若是這些想法把您搞糊塗了，沒必要擔憂；這是正常的反應。

閱讀 參考資料中 Tismer 的背景文章是進一步理解的良好開端。最好在閱讀該文章後繼續閱讀他的參考資料。但對目前來講，讓咱們在更通常的級別上與 Tismer 進行交談：

Mertz：Stackless Python 確切來講是什麼？有什麼初學者能夠理解的概念可以解釋有關 Stackless 的不一樣之處？

Tismer：Stackless Python 是一種不在 C 堆棧上保存狀態的 Python 實現。它的確有堆棧 -- 要多少有多少 -- 但這些是 Python 堆棧。

C 堆棧不能從例如 C 這樣的語言以乾淨的方式進行修改，除非以預期的順序進行。它對您施加了很大限制：您必須回到這裏，與您離開的方向正好相反。

「普通的」程序員一開始不會認爲這是個限制。他們必須從開始就要學會將想法轉向堆棧。堆棧沒有什麼壞處，而且一般它們施加的執行順序就是實際上的順序，但這並不意味着咱們必須等待一個這樣的堆棧序列完成才能運行另外一序列。

程序員在必須執行非阻塞調用和回調時意識到這一點。堆棧忽然擋住去路，咱們必須使用線程，或將狀態明確存儲在對象中，或者構建顯式的可切換堆棧等等。Stackless 的目的是幫助程序員避免這些問題。

Mertz：Stackless 的目標是達到與 CPython 100% 二進制兼容。是嗎？

Tismer：Stackless 此刻就是 100% 的二進制兼容。這意味着：安裝了 Python 1.5.2 後，用個人 Python15.dll 替換，每一個文件仍能工做，包括每一個擴展模塊。這不是目標，而是要求，由於我不但願關注全部擴展。

Mertz：我認爲 Stackless Python 絕對能吸引人們對它加以瞭解。和大多數講實際的程序員同樣，我在徹底理解它時遇到了難題，但這是使它顯得特別有趣的一部分。

Tismer：是啊，我也很講實際，您能夠想象在沒有任何持續性概念，而且不知道在 Python 中它究竟是什麼樣的狀況下實現這樣一件東西有多困難。沒法想象某些事物，但要投入去作是我最大的挑戰。完成後就很容易想象，也很容易從新設計。但在六個月的全職工做中，我猜有五個月的時間是在凝視屏幕和敲打鍵盤。

延續性很難銷售。協同程序和生成器，特別是微線程還稍容易一點。全部以上產品都  能夠在沒有顯式持續性的狀況下實現。但有了持續性後，會發現轉向其它結構所花費的步驟很是少，持續性就是使用的方法。因此我要改變個人營銷策略，再也不嘗試銷售持續性，而是它們的成果。對於可以看到光明的人來講，持續性仍然存在。

Mertz：有一個關於美國工程師和法國工程師的笑話。美國小組給法國小組帶來一個原型。法國小組的反應是：「它在實踐中工做得不錯；但在理論上靠得住嗎？」我想這個笑話多是要嘲弄一下「法國人」的做風，但在我本身看來，我徹底認同「法國人」的反應。排除笑話中任何針對特定民族的刻板模式，對它的認同是吸引我去了解 Stackless 的緣由。CPython 在實踐中使用，而 Stackless 在理論中使用！（換句話說，對於我我的，持續性的抽象純粹性比微線程的上下文切換加速更有趣）。

Tismer：我也有相似的感受。認識到 CPython 能夠在不涉及 C 堆棧的狀況下實現後，我確信它  必須用這種方式實現；其它全部方法都很荒唐。CPython 已經爲框架對象付出了代價，但它使用 C 堆棧嘗試它們更是喪失了全部自由。我以爲我必須解放 Python。:-)

我 1999 年 5 月開始這個項目。Sam Rushing 曾對硬件協同程序的實現有過粗略的研究，因此一場有關 Python 設備的討論開始了。將堆棧複製作大量更改永遠也不能將它變成 Python，這一點當時就很清楚。但可移植的、乾淨實現的協同程序可能能夠。不幸的是，這是不可能的。五年前，Steve Majewski 在乎識到若是不徹底重寫 Python 就沒法解決這個問題以後就放棄了。

那就是挑戰所在。我必須查明它。它若是是可能的，我就實現它；若是不可能，我就要證實這種不可能性。不久之後，通過了首次考慮和嘗試後，Sam 告訴我有關 call/cc 以及它是如何強大。那時，我對它們在哪些方面比協同程序更強大一點概念也沒有，但我相信他並實現了它們；六七次之後，總要徹底重寫，使我有了更深刻的理解。

我但願最終可以以使人眼花繚亂的高速度建立線程，但個人初衷是發現究竟我能到達什麼地步。

Mertz：在實踐方面，Stackless 可能有哪些性能改進呢？這些改進在當前的實現中有多重要？它還有多少潛力可挖？哪些特定類型的應用程序最有可能從 Stackless 中受益？

Tismer：在當前的實現中，Stackless 比傳統調用方案來講並不佔太大的優點。普通的 Python 對新解釋器開始遞歸。Stackless 展開到一個調度器，而後從那裏啓動解釋器。這點幾乎同樣。實際的改進在於協同程序和線程的實現。它們須要由類模擬，或者須要是標準 Python 中的實際線程，但使用 Stackless，它們能夠更直接地實現。

若是不對操做碼集作巨大的更改，核心的更多改進就顯得不太可能。但一個具備對其它地方延續性更多內置支持的再實現能夠大大提升速度。

受益最大的那些特定應用程序多是 Swarm 仿真，或有許多角色扮演極小任務的多人遊戲。一例就是正在使用 Stackless Python 開發的 EVE 遊戲（請參閱下面的  參考資料）。

Mertz：對於將 Stackless 合併到 CPython 主流您以爲如何？Stackless 是做爲一個分支好呢，仍是成爲核心版本的話有些方面會更好？

Tismer：有一些支持和反對的爭論。反對：只要我不放棄 Stackless 實現，它就是個人，我不須要討論如何以及爲何的問題。但同時，我在盡力（但未能）追趕 CVS。最好讓其它人來作。

其它沒必要對稀奇古怪的事物感興趣的那些 Python 用戶根本不會認識 Stackless；只是事實上它碰巧更快，最大遞歸級別如今是一個選項而不是硬件限制。對每一個用戶還有另外一個保證：將有可醃製 (pickleable) 執行狀態。這意味着能夠在程序運行的時侯保存它，將它發送給朋友，而後繼續運行。

最後，假使個人全部東西都變成核心，我就徹底同意；但我不但願看到一個就好象建議過屢次的不完整的解決方案。

Mertz：對 Stackless 的將來方向有什麼想法嗎？將生產什麼新的不一樣產品？Stackless 仍然受一些遞歸的困擾。它們會消失嗎？

Tismer：將部分地實現醃製支持。首先對於微線程使用，由於如今它們提供最乾淨的概念。它們在「潔淨室」裏生活，這裏不存在餘下的遞歸問題。個人最終目標是從 Python 中除去  所有解釋器遞歸。Stackless 的某些部分仍舊有遞Stackless Python：採訪創始人 Christian Tismer定義的 __xxx__ 方法。要定案很難，由於咱們須要更改不少東西、添加新的操做碼、展開某些內部調用序列等等。