This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Allow to provide custom exception handler to
Type: enhancement Stage: resolved
Components: asyncio Versions: Python 3.8
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 2022-04-11 14:59 by admin. 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:, *, 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()
  # other code

We don't want to add new arguments to as there would be too many.
msg373226 - (view) Author: (tomaszdrozdz) * Date: 2020-07-07 14:22  

Here we can read:  

Application developers should typically use the high-level asyncio functions, such as, 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  

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
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(...), 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():

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.
Date User Action Args
2022-04-11 14:59:33adminsetgithub: 85374
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 -> Allow to provide custom exception handler to
2020-07-03 14:26:06tomaszdrozdzcreate