STINNER Victor added the comment: I see different issues in your example:
* If the coroutine raises an exception which doesn't inherit from Exception (but inherits from BaseException), run_until_complete() doesn't consume the exception from the temporary task object => run_until_complete(coroutine) sets the _log_destroy_pending attribute of the temporary Task to False, but this attribute controls the "Task was destroyed but it is pending!" warning. The "%s exception was never retrieved" warning is controlled by the Future._log_traceback attribute (in Python 3.4+). This attribute is set to True in Future.set_exception().* * If a Task is deleted late during Python shutdown, the logging module fails to log the traceback because the builtin function has been deleted. => IMO it's an issue in the traceback module. It may catch the AttributeError on the call to linecache.getline(). It's not convinient to get a new exception (traceback) when trying to display a traceback... Maybe the traceback can check if Python is exiting before calling the linecache module? * If you call again loop.run_forever(): it exits immediatly because a call to loop.stop() was scheduled by future.set_exception() => I created the issue #22429 I don't think that it's a bug that Task._step() calls set_exception() for BaseException. Otherwise, how do you know that a task failed? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22428> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
