今天，我发现了一个名为trio的库，它自称是一个供人类使用的异步 API。requests这些词与'有点相似。requests确实是一个很好的图书馆，我想知道trio.
关于它的文章并不多，我只是找到一篇讨论curio和的文章asyncio。令我惊讶trio的是，它说自己甚至比curio（下一代古玩）还要好。
看了一半的文章，我找不到这两个异步框架的核心区别。它只是给出了一些curio实现比asyncio's 更方便的例子。但底层结构几乎相同。
那么有人可以给我一个我必须接受trio或curio优于的理由asyncio吗？或者解释一下为什么我应该选择trio而不是 built-in asyncio？
我来自哪里：我是三重奏的主要作者。我也是 curio 的主要贡献者之一（并撰写了您链接到的有关它的文章），并且是一名 Python 核心开发人员，他积极参与了有关如何改进 asyncio 的讨论。
在 trio（和古玩）中，核心设计原则之一是您永远不要使用回调进行编程；感觉更像是基于线程的编程而不是基于回调的编程。我想如果你打开引擎盖看看它们是如何在内部实现的，那么它们在某些地方使用回调，或者如果你眯着眼睛看就相当于回调的东西。但这就像说 Python 和 C 是等价的，因为 Python 解释器是用 C 实现的。你从不使用回调。
反正：
第一个重大区别是生态系统成熟度。当我在2018 年 3 月写这篇文章时，支持 asyncio 的库比支持 trio的库要多得多。例如，目前还没有任何真正的 HTTP 服务器支持 trio。PyPI 上的Framework :: AsyncIO 分类器目前有 122 个库，而Framework :: Trio 分类器只有 8 个。我希望这部分答案很快就会过时——例如，这里是 Kenneth Reitz 的实验在下一个版本的请求中添加三重奏支持——但是现在，你应该预料到，如果你对任何复杂的事情都是三人组，那么你会遇到需要自己填写而不是从 pypi 获取库的缺失部分，或者你需要使用trio-asyncio 包，可让您在 trio 程序中使用 asyncio 库。（三人组聊天频道有助于了解可用的内容以及其他人正在处理的内容。）
就实际库而言，它们也有很大不同。trio 的主要论点是它使编写并发代码比使用 asyncio 简单得多。当然，你最后一次听到有人说他们的库让事情变得更难使用是什么时候......让我举一个具体的例子。在本次演讲（幻灯片）中，我使用了实现RFC 8305“Happy eyeballs”的示例，这是一种用于有效建立网络连接的简单并发算法。这是Glyph的东西多年来一直在思考，他最新的 Twisted 版本大约有 600 行。（Asyncio 大致相同；Twisted 和 asyncio 在架构上非常相似。）在演讲中，我会教你使用 trio 在 40 行以内实现它所需知道的一切（我们在他的版本中修复了一个错误，同时我们'重新开始）。所以在这个例子中，使用 trio 可以让我们的代码简单一个数量级。
为什么会这样？这是一个更长的答案:-)。我正在逐渐致力于在博客文章和演讲中撰写不同的文章，并且我会尽量记住在链接可用时更新此答案。基本上，归结为 Trio 拥有一小组精心设计的原语，这些原语与我所知道的任何其他库有一些根本性的不同（当然，它建立在很多地方的想法之上）。这里有一些随机笔记给你一些想法：
在 asyncio 和相关库中，一个非常非常常见的问题是您调用some_function()，然后它返回，所以您认为它已经完成 - 但实际上它仍在后台运行。这会导致各种棘手的错误，因为它很难控制事情发生的顺序，或者知道任何事情何时真正完成，并且它可以直接隐藏问题，因为如果后台任务因未处理的异常而崩溃，asyncio 将通常只是在控制台上打印一些东西，然后继续。在 trio 中，我们通过“nurseries”处理任务产生的方式意味着这些事情都不会发生：当一个函数返回时，你就知道它已经完成了，并且 Trio 目前是唯一的 Python 并发库，异常总是传播直到你捕获它们。
Trio 管理超时和取消的方式很新颖，我认为比以前最先进的系统（如 C# 和 Golang）要好。实际上，我确实为此写了一篇完整的文章，所以我不会在这里详述所有细节。但是 asyncio 的取消系统——或者实际上是系统，其中有两个语义略有不同——基于一套比 C# 和 Golang 更古老的思想，并且难以正确使用。（例如，代码很容易通过生成后台任务而意外“逃脱”取消；请参阅上一段。）
在 asyncio 中有大量多余的东西，这使得很难判断 when 使用哪个东西。你有 futures、tasks 和 coroutines，它们基本上都用于相同的目的，但你需要知道它们之间的区别。如果你想实现一个网络协议，你必须选择是使用协议/传输层还是流层，它们都有棘手的陷阱（这是你链接的文章的第一部分的内容）。
Trio 是目前唯一的 Python 并发库，其中 control-C 可以按照您期望的方式工作（即，KeyboardInterrupt无论您的代码在哪里，它都会引发）。这是一件小事，但它有很大的不同:-)。由于各种原因，我认为这在 asyncio 中是不可修复的。
如果您需要在下周将某些东西交付到生产环境，那么您应该使用 asyncio（或者 Twisted、Tornado 或 gevent，它们更加成熟）。他们拥有庞大的生态系统，其他人在你之前就已经在生产中使用了它们，而且他们不会去任何地方。
如果尝试使用这些框架让您感到沮丧和困惑，或者如果想尝试不同的做事方式，那么请务必查看 trio——我们很友好 :-)。
如果您想在一年后将某些东西交付生产……那我不知道该告诉您什么。Python 并发不断变化。Trio 在设计层面有很多优势，但这足以克服 asyncio 的领先优势吗？asyncio 在标准库中是优势还是劣势？（注意现在每个人都是如何使用urllibrequests的，尽管标准库有urllib。） trio 中有多少新想法可以添加到 asyncio 中？没人知道。我希望今年在 PyCon 上会有很多有趣的讨论 :-)。