I think it's too late to change the cancellation logic. Cancellation is
tricky.
On Sun, Dec 3, 2017 at 1:53 PM, Chris Jerdonek
wrote:
> On Sun, Dec 3, 2017 at 9:04 AM, Guido van Rossum wrote:
> > Sounds like an implementation issue. The Future class has a boolean flag
> > indicating whether it'
On Sun, Dec 3, 2017 at 9:04 AM, Guido van Rossum wrote:
> Sounds like an implementation issue. The Future class has a boolean flag
> indicating whether it's been cancelled, and everything then raises
> CancelledError when that flag is set. I suppose we could replace that flag
> with an instance of
Sounds like an implementation issue. The Future class has a boolean flag
indicating whether it's been cancelled, and everything then raises
CancelledError when that flag is set. I suppose we could replace that flag
with an instance of CancelledError, and when we *catch* CancelledError we
set it to
IIRC at very early stages Guido van Rossum decided to *freeze*
`CancelledError`: user code should not derive from the exception. Like you
never derive from StopIteration.
On Sun, Dec 3, 2017 at 8:00 AM Chris Jerdonek
wrote:
> Hi, I want to ask how people feel about the following.
>
> If you rais
Hi, I want to ask how people feel about the following.
If you raise a subclass of CancelledError from within a task and then
call task.result(), CancelledError is raised rather than the subclass.
Here is some code to illustrate:
class MyCancelledError(CancelledError): pass
async def rai
