Yury Selivanov <yseliva...@gmail.com> added the comment:
> One reason why Task.cancel() is an incomplete replacement for > Task.set_exception() is that you don't have an easy way to communicate why > the task was ended. The result of the Task is bound to the result of the coroutine it wraps. If the coroutine raises an exception -- that's the exception of the Task object. If the coroutine returns a value -- that's the result value of the Task object. If the coroutine is cancelled via the "Task.cancel()" call -- asyncio.CancelledError is likely the result of the Task. Key rule: the wrapped coroutine dictates the result of the Task, not the other way around. The Task can signal cancellation, but even then, the final result is up to the coroutine. There's no clear reason to complicate the Task<->coroutine relationship by allowing to inject arbitrary exceptions into running coroutines. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32363> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
