我最近一直在閱讀約Stackless Python，與香草cPython相比，它似乎有很多優勢。它具有像無限遞歸，微線程，延續等很酷的功能，同時比cPython更快（大約10％，如果the Python wiki可以相信）和兼容它（至少版本2.5,2.6和3.0）。Stackless Python的缺點是什麼？
所有這些看起來都太好了，以至於沒有。然而，TANSTAAFL，我看不到Python社區中Stackless的熱情，而PEP 219從未實現過。這是爲什麼？ Stackless有什麼缺點？ Stackless'衣櫃裏藏着什麼骷髏？
（我知道無堆棧不提供真正的併發性，只是在並行方式編程更簡單的方法，它並沒有真正困擾我。）
我不知道Wiki上的「Stackless速度快10％」是從哪裏來的，但是我再也沒有試過測量這些性能數字。我無法想象Stackless如何做出重大改變。
Stackless是一個驚人的工具，帶有幾個組織/政治問題。
第一個來自歷史。 Christian Tismer開始談論10年前最終變成Stackless的事情。他了解他想要什麼，但很難解釋他在做什麼，爲什麼人們應該使用它。這部分是因爲他的背景沒有關於協同程序這樣的想法的CS培訓，並且因爲他的演示和討論都是以實現爲導向的，所以對於那些還沒有深入瞭解的人來說，很難理解如何使用它作爲解決方案他們的問題。
因此，最初的文檔很差。有關於如何使用它的一些描述，以及來自第三方貢獻者的最佳描述。根據PyCon的調查數據，在PyCon 2007上，我發表了一篇關於「Using Stackless」的演講，該演講非常好。 Richard Tew在收集這些內容方面做得非常好，更新了stackless.com，並在新的Python發行版出現時保持分發。他是EVE Online的開發者CCP Games的僱員，該開發者使用Stackless作爲其遊戲系統的重要組成部分。
CCP遊戲也是人們談論Stackless時最大的現實世界範例。 Stackless的主要教程是Grant Olson的「Introduction to Concurrent Programming with Stackless Python」，它也是面向遊戲的。我認爲這給人們一個傾斜的想法，即Stackless是面向遊戲的，當時更多的是遊戲更容易延續。
另一個困難是源代碼。在原來的形式中，它需要對Python的許多部分進行更改，這讓Python的領導者Guido van Rossum非常警惕。我認爲其中一部分原因是對call/cc的支持，後來被刪除爲「當有更好的更高級別的表單時，就像支持goto一樣」。我對這段歷史並不確定，所以請閱讀本段文字爲「Stackless曾經需要太多改變。」
後來的版本不需要更改，Tismer繼續推動將它包含在Python中。雖然有一些考慮，但官方立場（據我所知）是CPython不僅是一個Python實現，而且它是一個參考實現，它不包含Stackless功能，因爲它不能由Jython實現或鐵蟒。
絕對沒有「對代碼庫有重要修改的計劃」。這個來自Arafangion的報價和參考超鏈接（見評論）大約在2000/2001年。結構變化早已完成，這就是我上面提到的。現在堆積如山是穩定和成熟的，在過去的幾年裏只對代碼庫做了一些小小的調整。
Stackless的最後一個限制 - 沒有強大的Stackless支持者。 Tismer現在深深地參與了PyPy，這是Python的Python實現。他已經在PyPy中實現了Stackless功能，並認爲它比Stackless本身優越得多，並且認爲PyPy是未來的方式。 Tew保持Stackless，但他對宣傳不感興趣。我考慮過扮演這個角色，但看不到我能從中獲得收入。
雖然如果你想在Stackless培訓，請隨時contact me！ :)
我也有興趣在這裏的答案。我用Stackless玩過了一下，看起來這對標準Python來說是一個很好的補充。
如果Python想要更改爲不同的堆棧，PEP 219確實提到了從C代碼調用Python代碼的潛在困難。需要有方法來檢測和防止這種情況（避免垃圾堆棧）。我認爲這很容易理解，所以我也想知道爲什麼Stackless必須獨立。
如果我沒記錯的話，Stackless將被列入官方CPython，但Stackless的作者告訴CPython人員不要這樣做，因爲他計劃對代碼庫做一些重大更改 - 可以推測他希望稍後項目更成熟時進行整合。
來源？我覺得這很有趣，但我顯然無法相信你，因爲你這麼說。如果你錯了，我會看起來很傻，我開始討論它有多有趣。 – 2009-02-26 04:18:35
優秀的點。對不起，我沒有參考資料，因爲它在freenode的#python中進行了irc對話，但是我確實設法在http://gnosis.cx/download/charming_python_10_outtakes.html上找到一個古老的郵件列表對話，它提供了很多對情況更有見識。 – Arafangion 2009-02-26 04:48:46
找到這個討論花了相當長的時間。在那個 的時間，我不是在PyPy上，而是和psyco有了2年的戀情，直到健康完全停止了這一切。我現在再次活躍並設計了一種替代方法 - 將在EuroPython 2012上展示它。
安德魯斯的大部分陳述都是正確的。一些 小增加：
Stackless比10年前的CPython快得多，因爲我優化了解釋器循環。當時，圭多還沒有做好準備。幾年後，人們做了類似的優化，甚至更多更好的，這使得Stackless有點慢，正如預期的那樣。
關於包含：嗯，一開始我非常堅強，並且相信Stackless是一條路。後來，當它幾乎可能被包括在內時，我對此失去了興趣，並且寧願讓它保持這種狀態，部分地出於挫折感，部分地對 保持對Stackless的控制。
像「其他實現不能這樣做」的論點總是對我跛腳，因爲還有其他例子可以使用這個參數。我想我最好忘了這一點，並與Guido保持友好的關係，並擁有自己的發行版。
同時事情正在改變。我工作的PyPy和無堆棧作爲擴展將談論有時後
乾杯克里斯 -
PEP 219是9歲和嚴重過時。 「從C代碼調用Python代碼」的困難僅在PEP中討論的實現中，並且不在Stackless中。 PEP（「Stackless Python」）的名稱有點用詞不當，它從Stackless中吸取了靈感，就是這樣。 – 2009-02-26 13:00:02