[issue35812] Don't log an exception from the main coroutine in asyncio.run()

Andrew Svetlov added the comment: Nevermind. Actually, I used a backport `asyncio.run()` to Python 3.6. I saw the problem because of the difference between `asyncio.all_task()` and `asyncio.Task.all_task()`. The former return only active tasks but the later returns done tasks also.

[issue35812] Don't log an exception from the main coroutine in asyncio.run()

Change by Andrew Svetlov : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue35812] Don't log an exception from the main coroutine in asyncio.run()

Carlos Damázio added the comment: Hey, Andrew. I'd like to work on the issue, if anyone else hasn't done it yet. -- nosy: +Carlos Damázio ___ Python tracker ___ ___

[issue35812] Don't log an exception from the main coroutine in asyncio.run()

Change by Emmanuel Arias : -- nosy: +eamanu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue35812] Don't log an exception from the main coroutine in asyncio.run()

Henry Chen added the comment: I'm having trouble reproducing this issue. The main_coro seems to disappear when an exception is raised in it, so that it does not show up in the set of tasks to cancel. I'm probably misunderstanding something basic here. Is it possible to provide a minimal exam

[issue35812] Don't log an exception from the main coroutine in asyncio.run()

New submission from Andrew Svetlov : We use `asyncio.run()` (well, a backported to python3.6 private copy) in our application. The problem is: when `asyncio.run(main_coro(args))` raises an exception it is both raised to a caller and passed to `loop.call_exception_handler()` by `_cancel_all_t