asyncioとtrioの主な違いは何ですか？
今日、私は trio という名前のライブラリを見つけました。これは、それ自体が人間のための非同期APIであると言います。これらの単語はrequests 'と少し似ています。 requestsは本当に優れたライブラリであるため、trioの利点は何だと思います。
それについての記事はあまりありませんが、curioとasyncioについて議論している 記事 を見つけました。驚いたことに、trioは、それ自体がcurio（次世代キュリオ）よりも優れていると言います。
記事の半分を読んだ後、これらの2つの非同期フレームワークのコアの違いを見つけることができません。 curioの実装がasyncioの実装よりも便利な例をいくつか示しています。しかし、基礎となる構造はほぼ同じです（コールバックベース、非同期IOフレームワークは例外なくコールバックに基づいていると思います。）
だから、誰かが私にtrioまたはcurioがasyncioより優れているということを受け入れなければならない理由を教えてもらえますか？または、組み込みのtrioの代わりにasyncioを選択する理由について詳しく説明してください。
どこから来たのか：私はトリオの第一著者です。私はまた、curioの主要な貢献者の1人であり（リンク先の記事についても書いています）、asyncioの改善方法に関する議論に深く関わっているPython core dev.
コールバックについて何を意味するのかわかりません。トリオ（およびキュリオ）でのコア設計原則の1つは、コールバックを使用してプログラムしないことです。コールバックベースのプログラミングよりもスレッドベースのプログラミングのように感じます。フードを開いて内部での実装方法を確認すると、コールバックを使用する場所、または目を細めるとコールバックに相当するものがあると思います。しかし、これはPythonとCは同等であるため、PythonインタープリターはCで実装されています。Yoはコールバックを使用しないでください。
とにかく：
トリオvs非同期
Asyncioはより成熟しています
最初の大きな違いは、生態系の成熟度です。これをMarch 2018で書いている時点で、many trioサポートよりもasyncioサポートが多いライブラリがあります。たとえば、現在、トリオをサポートする実際のHTTPサーバーはありません。 Framework :: PyPI のAsyncIO分類器には現在122個のライブラリがあり、 Framework :: Trio分類器 回答のこの部分がすぐに古くなってしまうことを望んでいます。たとえば、 hereは、次のバージョンのリクエストでトリオのサポートを追加する実験をしています -しかし、今は、複雑なことをトリオでやっていると、pypiからライブラリを取得するのではなく、自分で記入する必要があるか、または trio-asyncioパッケージを使用すると、trioプログラムでasyncioライブラリを使用できます 。 （ trio chat channel は、何が利用可能か、他の人々が何に取り組んでいるかを知るのに役立ちます。）
トリオはコードをよりシンプルにします
実際のライブラリに関しては、それらも非常に異なっています。 trioの主な論点は、asyncioを使用するよりもはるかに簡単に並行コードを書くことができるということです。もちろん、誰かが自分のライブラリが物事を使いにくくすると言っているのを最後に聞いたのはいつですか...具体的な例を挙げましょう。 this talk （ slides ）では、 を実装する例を使用しますRFC 8305「Happy eyeballs」 。これは、ネットワーク接続を効率的に確立するために使用される単純な並行アルゴリズムです。これは Glyph が何年も考えてきたことであり、Twistedの彼の最新バージョンは最大600行です。 （Asyncioもほぼ同じです。Twistedとasyncioはアーキテクチャ上非常に似ています。）講演では、トリオを使用して40行未満で実装するために知っておく必要があることをすべて教えます（そして、再）。したがって、この例では、トリオを使用すると文字通りコードが1桁簡単になります。
また、ユーザーからのこれらのコメントが興味深いと思うかもしれません： 1 、 2 、 3
詳細には多くの違いがあります
なぜこれが起こるのですか？それははるかに長い答えです:-)。ブログの投稿や講演でさまざまな部分を作成することに徐々に取り組んでいます。リンクが利用可能になったら、この回答を更新することを忘れないでください。基本的に、Trioには、私が知っている他のライブラリとは基本的に異なるいくつかの慎重に設計されたプリミティブがあります（もちろん、多くの場所からのアイデアに基づいています）。アイデアを与えるためのランダムなメモを次に示します。
Asyncioと関連ライブラリで非常によくある問題は、some_function()を呼び出すことであり、それが戻るため、完了したと思われますが、実際にはまだバックグラウンドで実行されています。これは、あらゆる種類のトリッキーなバグにつながります。これは、物事が発生する順序を制御すること、または実際に何かが終了したことを知ることが困難になるためです。また、バックグラウンドタスクが未処理の例外でクラッシュした場合、asyncioは通常は、コンソールに何かを印刷してから続行します。トリオでは、「nurseries」を介してタスクの生成を処理する方法は、これらのことは発生しないことを意味します。関数が返されたとき、それが完了したことがわかり、TrioはPython where例外は、キャッチするまで常に伝播します。
Trioのタイムアウトとキャンセルを管理する方法は斬新であり、C＃やGolangのような以前の最先端システムよりも優れていると思います。 私は実際にこれについてエッセイを書いたので、 なので、ここではすべての詳細には触れません。しかし、asyncioのキャンセルシステム、または実際には、わずかに異なるセマンティクスを持つ2つのシステムがありますが、C＃やGolangよりも古いアイデアセットに基づいており、正しく使用するのは困難です。 （たとえば、バックグラウンドタスクを生成することにより、コードが誤ってキャンセルを「エスケープ」するのは簡単です。前の段落を参照してください。）
Asyncioには多くの冗長なstuffがあり、どの がwhen を使用するかを判断しにくくします。先物、タスク、コルーチンがあり、これらは基本的にすべて同じ目的で使用されますが、それらの違いを知る必要があります。ネットワークプロトコルを実装する場合は、プロトコル/トランスポートレイヤーを使用するか、ストリームレイヤーを使用するかを選択する必要があり、どちらにも扱いにくい落とし穴があります（これは theの最初の部分ですあなたがリンクしたエッセイ は約）。
現在、Trioは、Python control-Cが期待どおりに動作する（つまり、コードがどこにあってもKeyboardInterruptを発生させる）の唯一の同時実行ライブラリです。これは小さなことです。 、しかしそれは大きな違いを生む:-)。さまざまな理由から、これはasyncioで修正できるとは思わない。
まとめ
来週実稼働環境に何かを出荷する必要がある場合は、asyncio（または、より成熟したTwistedまたはTornadoまたはgevent）を使用する必要があります。彼らは大規模な生態系を持ち、他の人々はあなたの前に生産でそれらを使用しており、どこにも行きません。
これらのフレームワークを使用しようとするとイライラして混乱したり、別の方法で実験したい場合は、間違いなくトリオをチェックしてください-私たちはフレンドリーです:-)。
1年後に何かを本番環境に出荷したい場合は、何を伝えればいいかわかりません。 Python並行性は流動的です。トリオには設計レベルで多くの利点がありますが、asyncioのヘッドスタートを克服するのに十分ですか？標準ライブラリにあるasyncioは利点ですか、それとも欠点ですか？（標準ライブラリには urllib がありますが、最近では誰もがrequestsを使用していることに注意してください。トリオの新しいアイデアをasyncioにいくつ追加できますか？今年はPyConでこれについて多くの興味深い議論があると思います:-)。