私は最近Stackless Pythonについて読んできましたが、それはバニラcPythonに比べて多くの利点があるようです。無限再帰、マイクロスレッド、継続などの優れた機能を備えており、同時にcPythonよりも高速です（the Python wikiと考えられる場合は約10％）と（バージョン2.5以上2.6 3.0）。Stackless Pythonの欠点は何ですか？
これらはすべて実際にはあまりにもよく見えます。しかし、TANSTAAFL、私はPythonコミュニティの中でStacklessの熱意はあまり見られません。PEP 219は決して実現していません。何故ですか？ Stacklessの欠点は何ですか？ Stacklessのクローゼットにはどのようなスケルトンが隠されていますか？
（私はスタックレスが同時な方法で実際の同時実行、プログラミングだけの簡単な方法を提供していません知っている。それは本当に私を気にしません。）
Wikiの「Stackless is 10％faster」がどこから来たのか分かりませんが、私は決してこれらのパフォーマンス番号を測定しようとはしませんでした。私はStacklessがそれほど大きな違いを生み出すことは考えられません。
スタックレスは、いくつかの組織的/政治的問題を抱えた素晴らしいツールです。
最初のものは過去のものです。 Christian Tismerは、約10年前に最終的にStacklessになったことについて話を始めました。彼は自分が望んでいたことを知っていましたが、彼が何をしているのか、そして人々がそれを使うべき理由を説明するのは苦労しました。これは部分的には、コルーチンのようなアイデアに関するCSトレーニングをバックグラウンドに持たなかったことと、プレゼンテーションとディスカッションが非常にインプリメンテーション指向であるため、コンティニュイションのヒントを深く理解していない人にとっては、彼らの問題。
そのため、最初の文書は貧弱でした。サードパーティの貢献者から最高のものを使って、それを使う方法についていくつかの説明がありました。 PyCon 2007では、PyConの調査番号によれば、私は "Using Stackless"という話をしました。 Richard Tewはこれらを収集し、stackless.comを更新し、新しいPythonリリースが登場したときに配布を維持するという素晴らしい仕事をしています。彼はCCP Gamesの従業員であり、ゲームシステムの不可欠な部分としてStacklessを使用するEVE Onlineの開発者です。
CCPゲームは、Stacklessについて話したときに人々が使用する最大の実例です。 Stacklessの主なチュートリアルはGrant Olsonの "Introduction to Concurrent Programming with Stackless Python"です。これはゲーム向けです。私はこれが、Stacklessがゲーム指向であるという歪んだ考えを人々に与えると思う。
もう一つの難点はソースコードです。元の形では、Pythonの多くの部分を変更する必要がありました.Gio van RossumはPythonの主導者でした。その理由の一部は、コール/ ccのサポートであり、後で「より高いレベルのフォームがある場合には、サポートをあまりにも多くするようなもの」として削除されたと考えられます。私はこの歴史についてはっきりしていないので、この段落を「あまりにも多くの変更を必要とするスタックレス」と読んでください。
リリースは変更を必要とせず、Tismerは引き続きPythonへの組み込みを推し進めました。いくつかの考察がありましたが、公式の姿勢（私が知る限り）は、CPythonはPythonの実装ではなく、リファレンス実装の意味であり、Jythonでは実装できないため、スタックレス機能は含まれませんまたはIron Python。
"コードベースの重要な変更"の計画はまったくありません。 Arafangionの引用と参照のハイパーリンク（コメント参照）は、およそ2000/2001のものです。構造の変更はずっと前から行われていますが、これは私が上で述べたことです。 Stacklessは今や安定して成熟しており、ここ数年でコードベースのわずかな調整が行われています。
Stacklessの最終的な制限は、Stacklessの強力な支持者はいません。 Tismerは現在、Python for Pythonの実装であるPyPyに深く関わっています。彼はPyPyでStackless機能を実装しており、Stackless自体よりも優れていると考えており、PyPyが未来の道だと感じています。テューはスタックレスを維持しているが、彼はアドボカシーには興味がない。私はその役割を果たしていると考えましたが、どうやって収入を得られるのか分かりませんでした。
スタックレスでトレーニングをしたい場合は、contact meにお気軽にお問い合わせください。 :)
私もここの答えに興味があります。私はStacklessで少し演奏しました。標準的なPythonに加えて、それは良い固体のように見えます。
PEP 219では、Pythonが別のスタックに変更したい場合、CコードからPythonコードを呼び出す際に潜在的な問題があると言及しています。これを検出して防止する方法が必要です（Cスタックを破棄しないようにする）。私はこれが扱いやすいと思うので、Stacklessがそれ自身で立つ必要があるのも不思議です。
スタックレスは公式のCPythonに含める予定だったが、スタックレスの作者は、CPythonの人に、コードベースのいくつかの重要な変更を計画していたので、そう言わなかった。おそらく、プロジェクトが成熟した後に統合が行われました。
ソース？私はこれが面白いと思っていますが、あなたがそう言ったからといって、あなたを信じることはできません。あなたが間違っていたら私は愚か者に見え、それがいかに面白いか話し始めました。 –
優れたポイント。申し訳ありませんが、参照がありません.freenodeの#pythonのircの会話の中にあったので、http://gnosis.cx/download/charming_python_10_outtakes.htmlで古いメーリングリストの会話を見つけることができました。状況へのより多くの洞察。 – Arafangion
そのリンクは本当に素晴らしいです。それは私の多くの質問に答えます。 –
この議論を見つけるのにかなり時間がかかりました。その 時には、私はPyPyにはいなかったが、健康がこれをすべて突然停止させるまで、サイコと2年の関係を築いた。私は今再びアクティブになっており、 代替アプローチを設計しています - EuroPython 2012にそれを提示します。
Andrewsのステートメントの大部分は正しいです。一部 マイナーな追加：
インタプリタループを最適化したため、スタックレスは10年前のCPythonよりも大幅に高速でした。その時、グイドはそれのために準備ができていませんでした。数年後、人々は同様の最適化とそれ以上の最適化を行い、期待どおりスタックレスを少し遅くしました。
私が非常に好きであり、最初はスタックレスが行く方法だと確信しました。後で、ほとんど入ることが可能になったとき、私はそれに興味を失い、 を部分的に欲求不満からこのようにとどめ、部分的に をスタックレスのコントロールを維持します。
この引数が使用できる他の例があるので、「他の実装ではできません」という引数は、常に私には不満を感じていました。私はそれをもっと忘れて、自分のディストリビューションを持ってグイドと良い友情にとどまると思った。
一方、物事は再び変化しています。拡張子は時々、後でそれについてお話しますと、私はPyPyとスタックレスに取り組んでいます
乾杯 - クリス
洞察に感謝、クリス。 :) –
PEP 219は、9歳と真剣に古くなっています。 「CコードからPythonコードを呼び出す」の難しさは、PEPで説明した実装だけであり、Stacklessではありません。 PEPの名前（「Stackless Python」）は、ちょっとした誤解です。それはStacklessからのインスピレーションを引いた、それだけです。 –