Allow to provide custom exception handler to asyncio.run()

[f65e2c72-abe7-48c7-ad2d-b5e33ab2465f]

BPO	41202
Nosy	@asvetlov, @1st1, @aeros, @tomaszdrozdz
PRs	python/cpython#21295

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['type-feature', '3.8', 'expert-asyncio'] title = 'Allow to provide custom exception handler to asyncio.run()' updated_at = user = 'https://github.com/tomaszdrozdz' ``` bugs.python.org fields: ```python activity = actor = 'aeros' assignee = 'none' closed = True closed_date = closer = 'aeros' components = ['asyncio'] creation = creator = 'tomaszdrozdz' dependencies = [] files = [] hgrepos = [] issue_num = 41202 keywords = ['patch'] message_count = 9.0 messages = ['372934', '373181', '373226', '373227', '373348', '373390', '373408', '373463', '373508'] nosy_count = 4.0 nosy_names = ['asvetlov', 'yselivanov', 'aeros', 'tomaszdrozdz'] pr_nums = ['21295'] priority = 'normal' resolution = 'wont fix' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue41202' versions = ['Python 3.8'] ```

[f65e2c72-abe7-48c7-ad2d-b5e33ab2465f]

I wish we had:

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

so we could provide custome exception handler function for the loop.

[1st1]

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.

[f65e2c72-abe7-48c7-ad2d-b5e33ab2465f]

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" ???

[asvetlov]

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.

[aeros]

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.

[f65e2c72-abe7-48c7-ad2d-b5e33ab2465f]

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 ?

[1st1]

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.

[f65e2c72-abe7-48c7-ad2d-b5e33ab2465f]

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 ?

[aeros]

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.