asyncio 中所有这些已弃用的“循环”参数是什么？

Question

中的许多函数asyncio都有不推荐使用的loop参数，计划在 Python 3.10 中删除。实例包括as_completed()，sleep()，和wait()。

我正在寻找有关这些参数及其删除的一些历史背景。

• loop解决了哪些问题？一开始为什么要使用它？
• 出了什么问题loop？为什么要大量删除？
• 什么取代了loop，现在它消失了？

Answer 1

loop解决了哪些问题？一开始为什么要使用它？

在 Python 3.6 之前，asyncio.get_event_loop()不能保证在从 asyncio 协程或回调调用时返回当前运行的事件循环。它将返回之前使用 设置的任何事件循环set_event_loop(some_loop)，或者由 asyncio 自动创建的事件循环。但是同步代码可以很容易地创建一个不同的循环another_loop = asyncio.new_event_loop()并使用another_loop.run_until_complete(some_coroutine()). 在这种情况下，get_event_loop()调用 insidesome_coroutine和它等待的协程将返回some_loop而不是another_loop. 这种事情在随便使用 asyncio 时不会发生，但必须由 async 库来解决，它们不能假设它们在默认事件循环下运行。（例如，在测试或一些涉及线程的用法中，人们可能希望在不干扰全局设置的情况下启动一个事件循环set_event_loop。）在上述情况下，库将提供显式loop参数，您将another_loop在其中传递，以及每当运行循环与使用asyncio.set_event_loop().

这个问题将在 Python 3.6 和 3.5.3 中修复，get_event_loop()如果从内部调用，则修改为可靠地返回运行循环，another_loop在上述场景中返回。Python 3.7 将另外引入get_running_loop()它完全忽略全局设置并始终返回当前正在运行的循环，如果不在其中则引发异常。有关原始讨论，请参阅此线程。

一旦get_event_loop()变得可靠，另一个问题是性能问题。由于一些非常频繁使用的调用需要事件循环，最值得注意的是call_soon，传递和缓存循环对象更有效。Asyncio 本身就是这样做的，许多库也纷纷效仿。最终在 Cget_event_loop()中加速，不再是瓶颈。

这两个更改使loop参数变得多余。

出了什么问题loop？为什么要大量删除？

与任何其他冗余一样，它使 API 复杂化并打开了出错的可能性。异步代码几乎不应该只是随机地与不同的循环通信，现在get_event_loop()既正确又快速，没有理由不使用它。

此外，通过典型应用程序的所有抽象层传递循环非常乏味。随着 async/await 成为其他语言的主流，很明显手动传播全局对象不符合人体工程学，程序员不应该要求这样做。

什么取代了loop，现在它消失了？

只需get_event_loop()在需要时用于获取循环。或者，您可以使用get_running_loop()断言循环正在运行。

在 Python 3.7 中，访问事件循环的需要有所减少，因为某些以前只能作为循环方法使用的函数，例如create_task，现在可以作为独立函数使用。