[issue38599] Deprecate creation of asyncio object when the loop is not running

Andrew Svetlov added the comment: Fixed by #42392 -- resolution: -> fixed stage: patch review -> resolved status: open -> closed superseder: -> remove the deprecated 'loop' parameter asyncio API versions: +Python 3.10 -Python 3.9 ___ Python tracke

[issue38599] Deprecate creation of asyncio object when the loop is not running

Change by Emmanuel Arias : -- pull_requests: +17576 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18195 ___ Python tracker ___ __

[issue38599] Deprecate creation of asyncio object when the loop is not running

Joongi Kim added the comment: It is also generating deprecation warning: > /opt/python/3.8.0/lib/python3.8/asyncio/queues.py:48: DeprecationWarning: The > loop argument is deprecated since Python 3.8, and scheduled for removal in > Python 3.10. > self._finished = locks.Event(loop=loop) --

[issue38599] Deprecate creation of asyncio object when the loop is not running

Emmanuel Arias added the comment: Hi, @asvetlov are you thinking something like the patch attached? -- keywords: +patch Added file: https://bugs.python.org/file48697/0001-Add-a-deprectation-warning-for-queue-w-o-event-runni.patch ___ Python track

[issue38599] Deprecate creation of asyncio object when the loop is not running

Change by Emmanuel Arias : -- nosy: +eamanu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue38599] Deprecate creation of asyncio object when the loop is not running

Callum Ward added the comment: Hi, I'm a new contributor and this issue looks like an interesting enhancement: is there any consensus forming on what we want to limit to e.g. raising depreciation warnings when these first-class classes are created without running event loop? -- nosy

[issue38599] Deprecate creation of asyncio object when the loop is not running

Andrew Svetlov added the comment: I'm pretty happy with asyncio.run() functionalit. I used run() for the bug demonstration, but the example can be rewritten easily without this function. The problem is not in run() but in an object lifecycle. Implicit loop creation plus module-level initial

[issue38599] Deprecate creation of asyncio object when the loop is not running

Yury Selivanov added the comment: > Well, I'm basically using a run method defined as a shorthand for > self.loop.run_until_complete (without closing loop, reusing it throughout). > It would be nice if asyncio.run could simply be used instead, but I > understand you're saying this is easier

[issue38599] Deprecate creation of asyncio object when the loop is not running

Berry Schoenmakers added the comment: Well, I'm basically using a run method defined as a shorthand for self.loop.run_until_complete (without closing loop, reusing it throughout). It would be nice if asyncio.run could simply be used instead, but I understand you're saying this is easier said

[issue38599] Deprecate creation of asyncio object when the loop is not running

Yury Selivanov added the comment: > It would be nice if asyncio.run() uses the default loop if it's available > (and not running), and that the default loop remains intact after the call > returns. Unfortunately it's not possible to implement that reliably and without a bunch of surprising

[issue38599] Deprecate creation of asyncio object when the loop is not running

Berry Schoenmakers added the comment: The current implementation of asyncio.run() is focused quite a bit on one-shot use. After the call returns, the default event loop is even gone: calling asyncio.get_event_loop() gives "RuntimeError: There is no current event loop in thread 'MainThread'."

[issue38599] Deprecate creation of asyncio object when the loop is not running

Andrew Svetlov added the comment: At least it is my learned lesson from aiohttp development. -- ___ Python tracker ___ ___ Python-b

[issue38599] Deprecate creation of asyncio object when the loop is not running

Andrew Svetlov added the comment: I have a different feeling: we should start raising deprecation for asyncio.Queue() if it is created without running event loop. It required `get_event_loop()` and `loop.is_running()` checks. Later the pair can be replaced with `get_running_loop()`. I think

[issue38599] Deprecate creation of asyncio object when the loop is not running

Yury Selivanov added the comment: Yes. As a remedy for this particular problem we can add checks here and there comparing `asyncio.get_running_loop()` and `self._loop`. Performance will suffer a bit but the usability will greatly improve. -- ___

[issue38599] Deprecate creation of asyncio object when the loop is not running

New submission from Andrew Svetlov : Consider the following code: import asyncio q = asyncio.Queue() async def main(): await asyncio.gather(q.put(1), q.get(1)) asyncio.run(main()) This code just hangs since run() creates a loop but queue is bound with another (default) event loop. Th