classification
Title: Allow to provide custom exception handler to asyncio.run()
Type: enhancement Stage: resolved
Components: asyncio Versions: Python 3.8
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: aeros, asvetlov, tomaszdrozdz, yselivanov
Priority: normal Keywords: patch

Created on 2020-07-03 14:26 by tomaszdrozdz, last changed 2020-07-11 03:08 by aeros. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 21295 closed tomaszdrozdz, 2020-07-03 15:04
Messages (9)
msg372934 - (view) Author: (tomaszdrozdz) * Date: 2020-07-03 14:26
I wish we had:  

asyncio.run(coro, *, debug=False, excepton_handler=None)

so we could provide custome exception handler function for the loop.
msg373181 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2020-07-06 21:47
The idiomatic way:


async def main():
  loop = asyncio.get_running_loop()
  loop.set_exception_handler(...)
  # other code

asyncio.run(main())

We don't want to add new arguments to asyncio.run as there would be too many.
msg373226 - (view) Author: (tomaszdrozdz) * Date: 2020-07-07 14:22
https://docs.python.org/3/library/asyncio-eventloop.html#error-handling-api  

Here we can read:  

Application developers should typically use the high-level asyncio functions, such as asyncio.run(), and should rarely need to reference the loop object or call its methods. This section is intended mostly for authors of lower-level code, libraries, and frameworks, who need finer control over the event loop behavior.  


So as I understand this - I should not use  
asyncio.get_running_loop  
loop.set_exception_handler(...)  

Or maybe event loop should not be in "Low level api"  ???
msg373227 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2020-07-07 16:03
I agree with Yuri.

Usually, you don't need overriding of the default exception handler.
Indeed, if you really need this low-level API I see nothing wrong with `asyncio.get_running_loop()` call.
msg373348 - (view) Author: Kyle Stanley (aeros) * (Python committer) Date: 2020-07-08 20:56
Yep, having to set a custom exception handler definitely constitutes as needing "finer control over the event loop behavior". There's absolute nothing wrong with using the low-level API when you need further customization, but we try to minimize the high-level API as much as possible to make it simple for the average user. I suspect that the majority of asyncio users don't have a need to customize the exception handler beyond the default settings.
msg373390 - (view) Author: (tomaszdrozdz) * Date: 2020-07-09 10:10
OK.  
I understand.  

So how about maybe:  

    def run(main, *, debug=False, loop=None):  
        ...  
    
        if loop:  
            loop = events.new_event_loop()

So we could customize loop like:  

    loop = events.new_event_loop()  
    loop.set_XXX(...)  
    asyncio.run(my_coro, loop=loop)  

Just what tehn with debug parameter ?
msg373408 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2020-07-09 17:37
> So how about maybe:   

That wouldn't work. You still haven't explained what's wrong with calling `loop = asyncio.get_running_loop()` inside `async def main()`. That literally solves all problems without the need of us modifying any APIs.
msg373463 - (view) Author: (tomaszdrozdz) * Date: 2020-07-10 11:26
I just wanted to call  

    def main():
        asyncio.run(...)

But I can go with Your aproach.  
Thanks for discusion.  

Should I set status for this issue for closed with resolution rejected ?  

Should I delete branch on my forked git repo ?
Can I delete my forked git repo ?
msg373508 - (view) Author: Kyle Stanley (aeros) * (Python committer) Date: 2020-07-11 03:08
> Should I set status for this issue for closed with resolution rejected ?

I'll proceed with closing the issue.

> Should I delete branch on my forked git repo ?
> Can I delete my forked git repo ?

Might as well delete the branch, but the forked repo might be useful to keep around should you choose to open a PR to CPython in the future (although you can also just create a new one later). If you are interested in working on something else in the future, I'd recommend looking at the "newcomer friendly"/"easy" issues, or just looking for an existing open issue that you're interested in helping with. In most cases, working with a clearly defined issue is much easier than trying to propose a new one and getting it merged.
History
Date User Action Args
2020-07-11 03:08:49aerossetstatus: open -> closed
resolution: wont fix
messages: + msg373508

stage: patch review -> resolved
2020-07-10 11:26:20tomaszdrozdzsetmessages: + msg373463
2020-07-09 17:37:46yselivanovsetmessages: + msg373408
2020-07-09 10:10:42tomaszdrozdzsetmessages: + msg373390
2020-07-08 20:56:36aerossetnosy: + aeros
messages: + msg373348
2020-07-07 16:03:32asvetlovsetmessages: + msg373227
2020-07-07 14:22:43tomaszdrozdzsetmessages: + msg373226
2020-07-06 21:47:22yselivanovsetmessages: + msg373181
2020-07-03 15:04:26tomaszdrozdzsetkeywords: + patch
stage: patch review
pull_requests: + pull_request20444
2020-07-03 15:03:32tomaszdrozdzsettitle: Allo to provide custom exception handler to asyncio.run() -> Allow to provide custom exception handler to asyncio.run()
2020-07-03 14:26:06tomaszdrozdzcreate