In fact, the documentation is quite clear about Task.cancel() being different than Future.cancel(). Logging a different message could highlight the fact that canceling a task does not change its state change.
Anyway, now I know that it's considered a bad practice not to let a task the chance to terminate properly. Cheers, Martin On Tuesday, August 5, 2014 7:33:55 PM UTC+2, Guido van Rossum wrote: > > You're not giving the task a chance to handle the cancel() (which it may > want to do using try/except). So I think technically it is correct that you > are seeing this warning in the logs. Maybe we could make it clearer by > logging a different message when _must_cancel is set? > > > On Tue, Aug 5, 2014 at 4:27 AM, Martin Richard <[email protected] > <javascript:>> wrote: > >> Hi, >> >> When cancelling a task outside of the loop, the task is still considered >> pending because the result (CancelledError) will only be set when the loop >> will try to run the task once more. >> >> In the current version of tulip (last revision from 30 July), a >> consequence of this is that the message "Task was destroyed but it is >> pending!" can be logged, which is not exactly true. >> >> I wrote a test case: >> >> import asyncio >> >> l = asyncio.get_event_loop() >> >> def raise_base_exception(): >> raise SystemExit() >> >> @asyncio.coroutine >> def coro(): >> l.call_soon(raise_base_exception) >> yield from asyncio.sleep(10) >> >> task = asyncio.async(coro()) >> >> try: >> l.run_forever() >> except BaseException: >> task.cancel() >> >> I'm not sure if the behavior can be considered as a bug in tulip or if >> it's because I rely on a bad design, but in this case I'm sure that when I >> except a BaseException, I don't want to run the loop anymore. >> >> A simple fix for this in tulip would be to set self._log_destroy_pending >> to False when calling cancel(). >> >> Cheers, >> Martin >> > > > > -- > --Guido van Rossum (python.org/~guido) >
