[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: To stop the discussion from happening in two places (sorry, Yury), I started a broader discussion on Async-sig with thread starting here: https://mail.python.org/pipermail/async-sig/2019-February/000548.html -- __

[issue32363] Deprecate task.set_result() and task.set_exception()

Andrew Svetlov added the comment: I agree with Yuri. `Task.set_exception()` (let's assume it works) is very dangerous: if cancellation exception doesn't bubble up from coroutine code there is a very high chance to get broken invariants and not-released resources. The same situation is possi

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: > Well, if you want to unconditionally end tasks you shouldn't write coroutines > that ignore CancelledErrors. Well, of course. But code can have bugs, and maybe you didn't write the coroutine because it's from a library that you don't control. In that case,

[issue32363] Deprecate task.set_result() and task.set_exception()

Yury Selivanov added the comment: >> There's no clear reason to complicate the Task<->coroutine relationship by >> allowing to inject arbitrary exceptions into running coroutines. > My comment was more about CancelledError rather than arbitrary exceptions. > You didn't reply to the part of m

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: > There's no clear reason to complicate the Task<->coroutine relationship by > allowing to inject arbitrary exceptions into running coroutines. My comment was more about CancelledError rather than arbitrary exceptions. You didn't reply to the part of my resp

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: A second reason why Task.cancel() seems to be an incomplete replacement: Task.set_exception() and Task.set_result() both give you a way to unconditionally end a task. With cancel() though, the docs say, "Task.cancel() does not guarantee that the Task will be

[issue32363] Deprecate task.set_result() and task.set_exception()

Yury Selivanov 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 ra

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: Correction: that should have been bpo-31033. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: > Use Task.cancel() or use a Queue to communicate with the task. 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. With set_exception() and set_result

[issue32363] Deprecate task.set_result() and task.set_exception()

Ilya Kulakov added the comment: cancel will work in my case, but it's somewhat limited. In other hand it's probably a job of a testing library to provide an utility function. -- ___ Python tracker _

[issue32363] Deprecate task.set_result() and task.set_exception()

Yury Selivanov added the comment: > My use case was outside control of otherwise unconditionally blocking task > (for tests only). What replacement (if any) would you suggest? Use Task.cancel() or use a Queue to communicate with the task. Your test code was working, but ultimately was creat

[issue32363] Deprecate task.set_result() and task.set_exception()

Ilya Kulakov added the comment: Andrew, Yury I test my lib against dev versions of Python and recently got an error in one of the tests due to the deprecation. I do not argue the reason behind removing this methods, but Task.set_exception was working for me in tests: https://github.com/Kent

[issue32363] Deprecate task.set_result() and task.set_exception()

Change by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue32363] Deprecate task.set_result() and task.set_exception()

Yury Selivanov added the comment: New changeset 0cf16f9ea014b17d398ee3971d4976c698533318 by Yury Selivanov in branch 'master': bpo-32363: Disable Task.set_exception() and Task.set_result() (#4923) https://github.com/python/cpython/commit/0cf16f9ea014b17d398ee3971d4976c698533318 -- _

[issue32363] Deprecate task.set_result() and task.set_exception()

Change by Yury Selivanov : -- keywords: +patch pull_requests: +4818 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue32363] Deprecate task.set_result() and task.set_exception()

Yury Selivanov added the comment: About the only use case I can come up with is subclassing asyncio.Task and overriding set_result and set_exception implementations. This use case has been broken (unintentionally) in Python 3.6, when we first implemented Task in _asynciomodule.c. C Task doe

[issue32363] Deprecate task.set_result() and task.set_exception()

Yury Selivanov added the comment: Actually, I don't think we need a deprecation period. Both methods are completely unusable now. Given: async def foo(): await asyncio.sleep(1) print('A') return 42 1. Let's try to use Task.set_result(): async def main(): f = asynci

[issue32363] Deprecate task.set_result() and task.set_exception()

Yury Selivanov added the comment: +1. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue32363] Deprecate task.set_result() and task.set_exception()

New submission from Andrew Svetlov : Task result is given from coroutine execution, explicit modification of the value should be deprecated and eventually removed. -- components: Library (Lib), asyncio messages: 308542 nosy: asvetlov, yselivanov priority: normal severity: normal status: