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?