I wish we had:  

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

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

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.

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

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.

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.

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 ?

> 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.

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 ?

> 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.