On 14-05-29 02:05 PM, Guido van Rossum wrote:
> Perhaps. Could I impose on you and ask you to (1) file a bug in the
> Tulip tracker describing the problem, and (2) develop a patch and send
> it for my review using Rietveld (codereview.appspot.com
> <http://codereview.appspot.com>)?
Sure, will try to complete that this weekend.
I poked a bit at an initial implementation, but I wanted to clarify
something before going too much further.
My understanding of the goal is that given a chain of futures, if one of
those futures is cancelled, that future and everything downstream is
cancelled, while nothing upstream is cancelled and instead B's
CancelledError is bubbled up.
So e.g. given A -> B -> C -> D, if B is cancelled, then so are C and D,
but A isn't, although A could be done with an exception if B's
CancelledError is uncaught.
Some of the unit tests assume that in this scenario A should be
cancelled too. For example, this Task unit test:
def test_cancel_inner_future(self):
f = asyncio.Future(loop=self.loop)
@asyncio.coroutine
def task():
yield from f
return 12
t = asyncio.Task(task(), loop=self.loop)
test_utils.run_briefly(self.loop) # start task
f.cancel()
with self.assertRaises(asyncio.CancelledError):
self.loop.run_until_complete(t)
self.assertTrue(f.cancelled())
*self.assertTrue(t.cancelled())*
With the change, t.cancelled() would be False, although t.done() would
be True.
Earlier you called it a subtle bug, but the unit tests are testing for
this behaviour, which means it's actually intentional design. So I
wanted to double check before going too far down a rabbit hole. Are you
in agreement that this behaviour should be changed, and the affected
unit tests updated to reflect this change? Or have I misunderstood the
intention?
Thanks!
