[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: New changeset da742ba826721da84140abc785856d4ccc2d787f by Chris Jerdonek in branch 'master': bpo-31033: Improve the traceback for cancelled asyncio tasks (GH-19951) https://github.com/python/cpython/commit/da742ba826721da84140abc785856d4ccc2d787f

[issue31033] Add argument to .cancel() of Task and Future

Yury Selivanov added the comment: Elevating to release blocker to make sure it's included. The PR is good. -- ___ Python tracker ___

[issue31033] Add argument to .cancel() of Task and Future

Change by Yury Selivanov : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: I just want to flag one issue after rebasing my traceback PR onto what was merged. If task.cancel() is called like this-- task.cancel("POSSIBLY LONG CANCEL MESSAGE") There is the question of whether the passed message should be repeated each time the

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: The msg argument has now been added (second PR). I'm going to keep this issue open until the traceback issue has also been addressed (the other PR), as that was one part of the discussions here. -- ___ Python

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: New changeset 1ce5841eca6d96b1b1e8c213d04f2e92b1619bb5 by Chris Jerdonek in branch 'master': bpo-31033: Add a msg argument to Future.cancel() and Task.cancel() (GH-19979) https://github.com/python/cpython/commit/1ce5841eca6d96b1b1e8c213d04f2e92b1619bb5

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: I also posted a second PR (separate from the first) that adds a "msg" argument to Future.cancel() and Task.cancel(). That PR is also now ready for review: https://github.com/python/cpython/pull/19979 The other PR is simpler and more essential though, so I

[issue31033] Add argument to .cancel() of Task and Future

Change by Chris Jerdonek : -- pull_requests: +19295 pull_request: https://github.com/python/cpython/pull/19979 ___ Python tracker ___

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: Okay, I completed my draft PR (both C and pure Python implementations are done). -- ___ Python tracker ___

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: I just posted a draft, proof-of-concept PR for one aspect of this issue: https://github.com/python/cpython/pull/19951 Namely, the PR makes it so that cancelled tasks have full tracebacks, all the way to where the code first gets interrupted. I did the C

[issue31033] Add argument to .cancel() of Task and Future

Change by Chris Jerdonek : -- keywords: +patch pull_requests: +19267 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19951 ___ Python tracker ___

[issue31033] Add argument to .cancel() of Task and Future

Alexander Mohr added the comment: @yselivanov even better :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue31033] Add argument to .cancel() of Task and Future

Change by Carl Meyer : -- nosy: +carljm ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31033] Add argument to .cancel() of Task and Future

Yury Selivanov added the comment: > I like the idea of having an argument to construct the CancelledError with, > but I like even more the ability to tell the exception that will be raised to > have the traceback of the point where the task was originally cancelled. Why

[issue31033] Add argument to .cancel() of Task and Future

Alexander Mohr added the comment: I was about to open a new bug, but I think my idea overlaps with this one. From what I understand there are two ways to cancel tasks: 1) calling task.cancel() 2) explicitly raising a CancelledError with #2 you can get a traceback by

[issue31033] Add argument to .cancel() of Task and Future

Марк Коренберг added the comment: 1. Yes, specifying argument to cancel in `raise CancelledError` would be perfect 2. specifying argument to `.cancel()` is still actual. 3. Yes, important part of exceptions should not be swallowed (please open separate issue). Also, it will be nice to show

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: A couple thoughts on this issue: First, I think the OP's original issue could perhaps largely be addressed without having to change cancel()'s signature. Namely, simply passing a hard-coded string to CancelledError in the couple spots that CancelledError is

[issue31033] Add argument to .cancel() of Task and Future

Changes by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker ___ ___

[issue31033] Add argument to .cancel() of Task and Future

Yury Selivanov added the comment: > Will it cancel whole chain of depending futures in a RIGHT way ? I was thinking about this: def Future.set_exception(exc): if isinstance(exc, asyncio.CancelledError): return self._cancel(exc) # here goes old code def

[issue31033] Add argument to .cancel() of Task and Future

Марк Коренберг added the comment: Hmmm task.set_exception(Exception('xxx')) Will it cancel whole chain of depending futures in a RIGHT way ? Or we must require exception passed here to be subclassed from CancelledError ? -- ___ Python tracker

[issue31033] Add argument to .cancel() of Task and Future

Yury Selivanov added the comment: > Yes, I agree with you about my weird way of debugging. But anyway, changing > API with adding ability to pass actual cause would be welcome. I'm not opposed to the idea, btw. If we do decide to add an argument to 'cancel', we probably should do the same for

[issue31033] Add argument to .cancel() of Task and Future

Марк Коренберг added the comment: Yes, I agree with you about my weird way of debugging. But anyway, changing API with adding ability to pass actual cause would be welcome. -- ___ Python tracker

[issue31033] Add argument to .cancel() of Task and Future

Stéphane Wirtel added the comment: you could use gdb or pdb for the debugging. -- nosy: +matrixise ___ Python tracker ___

[issue31033] Add argument to .cancel() of Task and Future

Yury Selivanov added the comment: Well, don't use "print(e)" when you are printing errors in in Python. This is pretty standard behaviour for all Python code, not just asyncio. A lot of code in stdlib raises exceptions, almost none allows to customize them. --

[issue31033] Add argument to .cancel() of Task and Future

New submission from Марк Коренберг: History: First, I tried to debug code around asyncio.Task() cancelling. So I wrote: = try: ... except Exception as e: print(e) = When task was cancelled, an empty string printed. I wondered why. So I change the code to print(repr(e))