python - asyncio 和 trio 之间的核心区别是什么？

Question

今天发现了一个名为trio的库它说它本身是一个供人类使用的异步 API。这些词和requests有点相似'。如 requests真是个好库，不知道trio有什么好处.
关于它的文章不多，我只是找了一个article讨论 curio和 asyncio .令我惊讶的是，trio说自己比curio还要好(下一代古玩)。
看了一半的文章，我找不到这两个异步框架的核心区别。它只是给出了一些例子 curio的实现比asyncio更方便的。但底层结构几乎相同。
那么有人能给我一个我必须接受的理由trio或 curio优于asyncio ?或者解释更多关于为什么我应该选择 trio而不是内置 asyncio ?

Answer 1

我来自哪里:我是三重奏的主要作者。我也是 curio 的主要贡献者之一(并撰写了您链接到的关于它的文章)，并且是一名 Python 核心开发人员，他积极参与了有关如何改进 asyncio 的讨论。
在 trio(和 curio)中，核心设计原则之一是永远不要使用回调进行编程；感觉更像是基于线程的编程而不是基于回调的编程。我想如果你打开引擎盖看看它们是如何在内部实现的，那么在某些地方它们会使用回调，或者如果你眯着眼睛看的话，它们有点相当于回调。但这就像说 Python 和 C 是等价的，因为 Python 解释器是用 C 实现的。你从不使用回调。
无论如何:
三重奏与异步
Asyncio 更成熟
第一个重大差异是生态系统的成熟度。在我在 March 2018 写这篇文章的时候，有更多的库支持 asyncio 而不是 trio 支持。例如，现在没有任何真正的支持三重奏的 HTTP 服务器。 Framework :: AsyncIO classifier on PyPI 目前有 122 个库，而 Framework :: Trio classifier 只有 8 个。我希望这部分答案很快就会过时——例如，here's Kenneth Reitz experimenting with adding trio support in the next version of requests——但现在，如果你是三重奏对于任何复杂的事情，那么您将遇到需要自己填写的缺失部分，而不是从 pypi 获取库，或者您需要使用 the trio-asyncio package that lets you use asyncio libraries in trio programs 。 (trio chat channel 可用于了解可用的内容以及其他人正在处理的内容。)
Trio 让你的代码更简单
就实际库而言，它们也大不相同。 trio 的主要论点是它使编写并发代码比使用 asyncio 简单得多。当然，你最后一次听到有人说他们的图书馆让东西更难使用是什么时候……让我举一个具体的例子。在 this talk ( slides ) 中，我使用了实现 RFC 8305 "Happy eyeballs" 的例子，它是一个简单的并发算法，用于高效建立网络连接。这是 Glyph 多年来一直在思考的事情，他最新的 Twisted 版本大约有 600 行。 (Asyncio 大致相同；Twisted 和 asyncio 在架构上非常相似。)在演讲中，我会教你使用 trio 在 40 行以内实现它所需的一切(并且我们修复了他版本中的错误，同时我们)重新开始)。所以在这个例子中，从字面上使用 trio 使我们的代码简单了一个数量级。
您可能还会发现用户的这些评论很有趣: 1 、 2 、 3
细节上有很多很多不同
为什么会发生这种情况？这是一个更长的答案:-)。我正在逐渐努力在博客文章和演讲中撰写不同的文章，并且我会尽量记住在链接可用时更新此答案。基本上，这归结为 Trio 拥有一小组精心设计的原语，这些原语与我所知道的任何其他库都有一些根本的区别(当然，当然建立在很多地方的想法之上)。以下是一些随机笔记，让您有所了解:
在 asyncio 和相关库中一个非常非常常见的问题是你调用 some_function() ，它返回，所以你认为它已经完成——但实际上它仍在后台运行。这会导致各种棘手的错误，因为它很难控制事情发生的顺序，或者知道任何事情什么时候真正完成，而且它可以直接隐藏问题，因为如果后台任务因未处理的异常而崩溃，asyncio 将通常只是在控制台上打印一些东西，然后继续。在 trio 中，我们通过“托儿所”处理任务生成的方式意味着这些事情都不会发生:当一个函数返回时，你就知道它已经完成了，而 Trio 是目前唯一的 Python 并发库，其中异常总是传播直到你捕捉到它们。
Trio 管理超时和取消的方式很新颖，我认为比以前最先进的系统(如 C# 和 Golang)更好。 I actually did write a whole essay on this, 所以我不会在这里详细介绍。但是 asyncio 的取消系统——或者说真的，系统，它有两个语义略有不同的系统——基于一套比 C# 和 Golang 更古老的思想，并且很难正确使用。 (例如，代码很容易通过生成后台任务意外地“逃避”取消；请参阅上一段。)
asyncio 中有大量冗余内容，即 can make it hard to tell which thing to use when 。你有 future 、任务和协程，它们基本上都用于相同的目的，但你需要知道它们之间的区别。如果你想实现一个网络协议(protocol)，你必须选择是使用协议(protocol)/传输层还是流层，它们都有棘手的陷阱(这就是 the essay you linked 的第一部分的内容)。
Trio 是目前唯一的 Python 并发库，其中 control-C 以您期望的方式工作(即，无论您的代码在哪里，它都会引发 KeyboardInterrupt)。这是一件小事，但它有很大的不同:-)。由于各种原因，我认为这在 asyncio 中无法解决。
总结
如果您需要在下周将某些东西交付生产，那么您应该使用 asyncio(或 Twisted、Tornado 或 gevent，它们甚至更成熟)。他们拥有庞大的生态系统，其他人在你之前已经在生产中使用过它们，而且他们不会去任何地方。
如果尝试使用这些框架让您感到沮丧和困惑，或者想要尝试不同的做事方式，那么一定要看看 trio——我们很友好 :-)。
如果你想从现在起一年后将某些东西交付生产......那么我不知道该告诉你什么。 Python 并发性不断变化。 Trio 在设计层面有很多优势，但这足以克服 asyncio 的领先优势吗？标准库中的 asyncio 是优势还是劣势？ (注意现在每个人都是如何使用 requests 的，即使标准库有 urllib 。) trio 中有多少新想法可以添加到 asyncio 中？没有人知道。我希望今年在 PyCon 上会有很多有趣的讨论:-)。