[issue39529] Deprecate get_event_loop()

Change by John Mellor : -- nosy: +johnmellor ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39529] Deprecate get_event_loop()

Ben Darnell added the comment: > In IPython, I think you could use new_event_loop() for getting a new loop > instance. > Then, save the loop reference somewhere as a direct attribute, > threading.local or ContextVar. > Calling loop.run_until_complete() looks pretty normal in your situation.

[issue39529] Deprecate get_event_loop()

Min RK added the comment: Oops, I interpreted "not deprecated by oversight" as the opposite of what you meant. Sorry! All clear, now. -- ___ Python tracker ___

[issue39529] Deprecate get_event_loop()

Andrew Svetlov added the comment: Ages ago, get_event_loop() did not return the current running loop if called from async function context; it returned a loop instance registered with previous set_event_loop(...) call instead. Later we fixed get_event_loop() behavior in 3.5.4 IIRC and added

[issue39529] Deprecate get_event_loop()

Min RK added the comment: Thank you! I think I have enough information to update. > IMHO, asyncio.set_event_loop()...[is] not deprecated by oversight. I'm curious, what is an appropriate use of `asyncio.set_event_loop()` if you can never get the event loop with `get_event_loop()`? If you

[issue39529] Deprecate get_event_loop()

Andrew Svetlov added the comment: IMHO, asyncio.set_event_loop() and policy.get_event_loop()/policy.set_event_loop() are not deprecated by oversight. In IPython, I think you could use new_event_loop() for getting a new loop instance. Then, save the loop reference somewhere as a direct

[issue39529] Deprecate get_event_loop()

Min RK added the comment: Further digging reveals that `policy.get_event_loop()` is _not_ deprecated while `asyncio.get_event_loop()` is. Is that intentional? Does that mean switching our calls to `get_event_loop_policy().get_event_loop()` should continue to work without deprecation?

[issue39529] Deprecate get_event_loop()

Min RK added the comment: The comments in this thread suggest that `set_event_loop` should also be deprecated, but it hasn't been. It doesn't seem to have any use without `get_event_loop()`. I'm trying to understand the consequences of these changes for IPython, and make the changes

[issue39529] Deprecate get_event_loop()

Kyle Stanley added the comment: > But why does `asyncio.run` unconditionally create a new event loop instead of > running on `asyncio.get_event_loop`? AFAIK, it does so for purposes of compatibility in programs that need multiple separate event loops and providing a degree of

[issue39529] Deprecate get_event_loop()

Ben Darnell added the comment: > The maintenance burden of the introduced deprecation should be pretty low. This is going to cause an unpleasant amount of churn in the Tornado community. It's been idiomatic (going back 12 years now) to do all your setup in synchronous code before starting

[issue39529] Deprecate get_event_loop()

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement versions: +Python 3.10 ___ Python tracker

[issue39529] Deprecate get_event_loop()

Serhiy Storchaka added the comment: New changeset 172c0f2752d8708b6dda7b42e6c5a3519420a4e8 by Serhiy Storchaka in branch 'master': bpo-39529: Deprecate creating new event loop in asyncio.get_event_loop() (GH-23554)

[issue39529] Deprecate get_event_loop()

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +22435 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23554 ___ Python tracker

[issue39529] Deprecate get_event_loop()

Serhiy Storchaka added the comment: The most visible effect in tests is that asyncio.gatcher() and some other synchronous functions will need a running loop if any of arguments is a coroutine. -- ___ Python tracker

[issue39529] Deprecate get_event_loop()

Andrew Svetlov added the comment: I think the deprecation of `set_event_loop()` is a good idea. The function is not required by `asyncio.run()` implementation. -- ___ Python tracker

[issue39529] Deprecate get_event_loop()

Serhiy Storchaka added the comment: I am writing a code (it is not trivial to emit correct warning) and I have a question. What to do if the loop was set by set_event_loop()? Currently get_event_loop() can return a loop without creating a new loop while get_running_loop() raises an error.

[issue39529] Deprecate get_event_loop()

Yury Selivanov added the comment: > For asyncio.Lock (plus other synchronization primitives) and asyncio.Queue, > this would be added in https://github.com/python/cpython/pull/18195. > Currently waiting on emanu (author of the PR) to finish up some changes, but > it's mostly complete. Could

[issue39529] Deprecate get_event_loop()

Kyle Stanley added the comment: FWIW, I agree with get_event_loop() being problematic with its error messages, and having a bit too much functionality in a single function from an API design perspective. It commonly comes up as an issue among asyncio users in communities that I'm active in.

[issue39529] Deprecate get_event_loop()

Yury Selivanov added the comment: I think we still use get_event_loop() in asyncio code, no? If we do, we should start by raising deprecation warnings in those call sites, e.g. if a Future or Lock is created outside of a coroutine and no explicit event loop is passed. We should do this in

[issue39529] Deprecate get_event_loop()

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39529] Deprecate get_event_loop()

Serhiy Storchaka added the comment: Yes, it is what I meant. Many code written before 3.7 use get_event_loop() because there was no get_running_loop() yet. Now, to avoid deprecation (and making the code more robust) it should be rewritten with using get_running_loop() or get_event_loop()

[issue39529] Deprecate get_event_loop()

Change by Andrew Svetlov : -- components: +asyncio nosy: +yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39529] Deprecate get_event_loop()

Andrew Svetlov added the comment: Serhiy, maybe I had not understood your proposal properly. If you are asking about deprecating get_event_loop() call from outside of async code but implicit call get_running_loop() without a warning if called from async function -- it sounds like a

[issue39529] Deprecate get_event_loop()

Andrew Svetlov added the comment: Currently, I'm talking about adding a deprecation only. The asyncio.get_event_loop() function will stay in Python for a while in deprecated status. I don't know the exact period but it should be 3 releases at least I guess, with possibly extending to 5

[issue39529] Deprecate get_event_loop()

Serhiy Storchaka added the comment: Will asyncio.get_event_loop() be removed or made an alias of asyncio.get_running_loop()? The latter could minimize the disruption of the existing code. -- nosy: +serhiy.storchaka ___ Python tracker

[issue39529] Deprecate get_event_loop()

New submission from Andrew Svetlov : Yuri proposed it for Python 3.8 but at that time the change was premature. Now we can reconsider it for 3.9 The problem is that asyncio.get_event_loop() not only returns a loop but also creates it on-demand if the thread is main and the loop doesn't exist.