这些不推荐使用的“循环”是什么？异步中的参数？ [英] What are all these deprecated "loop" parameters in asyncio?

问题描述

asyncio 中的许多函数已经弃用了 loop 参数，该参数计划在Python 3.10中删除。示例包括 as_completed（） ， sleep （） 和 wait（） 。

A lot of the functions in asyncio have deprecated loop parameters, scheduled to be removed in Python 3.10. Examples include as_completed(), sleep(), and wait().

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

I'm looking for some historical context on these parameters and their removal.

• 循环解决了什么问题？为什么一个人会首先使用它？


• 循环怎么了？为什么将其全部删除？


• 什么已经取代了循环，现在它消失了？

• What problems did loop solve? Why would one have used it in the first place?
• What was wrong with loop? Why is it being removed en masse?
• What replaces loop, now that it's gone?

推荐答案

循环解决了什么问题？为什么一个人会首先使用它？

What problems did loop solve? Why would one have used it in the first place?

在Python 3.6之前， asyncio.get_event_loop（） 不能保证从异步协程或回调调用时，返回当前正在运行的事件循环。它会返回先前使用 set_event_loop（some_loop）或由asyncio自动创建的事件循环设置的任何事件循环。但是同步代码可以轻松地使用 another_loop = asyncio.new_event_loop（）创建另一个循环，并使用 another_loop.run_until_complete（some_coroutine（））。在这种情况下， get_event_loop（）在 some_coroutine 内部调用，它等待的协程将返回 some_loop 而不是 another_loop 。随便使用asyncio不会发生这种情况，但是必须由异步库解决，因为异步库无法假定它们在默认事件循环下运行。 （例如，在测试或某些涉及线程的用法中，一个人可能希望启动一个事件循环，而又不会通过 set_event_loop 干扰全局设置。）这些库将提供显式的 loop 参数，在上述情况下您将传递 other_loop ，并且在运行循环不同时将使用该参数从使用 asyncio.set_event_loop（）设置的循环中。

Prior to Python 3.6, asyncio.get_event_loop() was not guaranteed to return the event loop currently running when called from an asyncio coroutine or callback. It would return whatever event loop was previously set using set_event_loop(some_loop), or the one automatically created by asyncio. But sync code could easily create a different loop with another_loop = asyncio.new_event_loop() and spin it up using another_loop.run_until_complete(some_coroutine()). In this scenario, get_event_loop() called inside some_coroutine and the coroutines it awaits would return some_loop rather than another_loop. This kind of thing wouldn't occur when using asyncio casually, but it had to be accounted for by async libraries which couldn't assume that they were running under the default event loop. (For example, in tests or in some usages involving threads, one might want to spin up an event loop without disturbing the global setting with set_event_loop.) The libraries would offer the explicit loop argument where you'd pass another_loop in the above case, and which you'd use whenever the running loop differed from the loop set up with asyncio.set_event_loop().

此问题为已修复在Python 3.6和3.5.3中，其中 get_event_loop（）已修改为可靠地返回正在运行的循环（如果从内部调用），在上述情况下返回 another_loop 。 Python 3.7还会引入 get_running_loop（） 会完全忽略全局设置，并始终返回当前正在运行的循环，如果不在其中则引发异常。请参阅此主题以获取原始讨论。

This issue would be fixed in Python 3.6 and 3.5.3, where get_event_loop() was modified to reliably return the running loop if called from inside one, returning another_loop in the above scenario. Python 3.7 would additionally introduced get_running_loop() which completely ignores the global setting and always returns the currently running loop, raising an exception if not inside one. See this thread for the original discussion.

一旦 get_event_loop（）变得可靠，另一个问题就是性能。由于某些频繁使用的调用需要事件循环，因此最值得注意的是 call_soon ，传递和缓存循环对象的效率更高。 Asyncio本身就是这样做的，许多库也纷纷效仿。最终 get_event_loop（）被在C中加速并被

Once get_event_loop() became reliable, another problem was that of performance. Since the event loop was needed for some very frequently used calls, most notably call_soon, it was simply more efficient to pass around and cache the loop object. Asyncio itself did that, and many libraries followed suit. Eventually get_event_loop() was accelerated in C and was no longer a bottleneck.

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

These two changes made the loop arguments redundant.

循环怎么了？为什么将其全部删除？

What was wrong with loop? Why is it being removed en masse?

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

As any other redundancy, it complicates the API and opens up possibilities for errors. Async code should almost never just randomly communicate with a different loop, and now that get_event_loop() is both correct and fast, there is no reason not to use it.

此外，在典型应用程序的所有抽象层之间传递循环也很繁琐。随着异步/等待在其他语言中成为主流，很明显，手动传播全局对象已不再符合人体工程学，程序员也不需要这样做。

Also, passing the loop through all the layers of abstraction of a typical application is simply tedious. With async/await becoming mainstream in other languages, it has become clear that manually propagating a global object is not ergonomic and should not be required from programmers.

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

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

Just use get_event_loop() to get the loop when you need it. Alternatively, you can use get_running_loop() to assert that a loop is running.

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

The need for accessing the event loop is somewhat reduced in Python 3.7, as some functions that were previously only available as methods on the loop, such as create_task, are now available as stand-alone functions.

这篇关于这些不推荐使用的“循环”是什么？异步中的参数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！