Agree with Aurelien Lambert: if you call task.cancel() there is no
sense for expecting a normal result from a task.
My typical code for task cancellation looks like
task.cancel()
with contextlib.suppress(asyncio.CancelledError):
await task
If you need a partial task result you probably can bu
Which means you cancel a running task but still have to wait for it and check
if it eventually has a result. This is OK for internal use, but highly counter
intuitive for the end-user. And it makes the cancelled status even more
inconsistent, as calling cancel on a running task does not ensure i
Aren't you able to catch the cancellation error and retrieve the data from
the inner task's .result()?
On Wed, Jul 31, 2019, 8:00 AM Guido van Rossum wrote:
> I wonder if Nathaniel has something to add? Trio has a different approayto
> cancellation. Of course it is also an entirely new library..
I wonder if Nathaniel has something to add? Trio has a different approayto
cancellation. Of course it is also an entirely new library...
On Tue, Jul 30, 2019 at 9:51 PM wrote:
> Oh only now it appears in the list ! I thought the post hadn't working, so
> I posted again :/.
>
> I've fixed my "lib
Oh only now it appears in the list ! I thought the post hadn't working, so I
posted again :/.
I've fixed my "library"
(https://github.com/aure-olli/aiokafka/blob/3acb88d6ece4502a78e230b234f47b90b9d30fd5/syncio.py),
and the `wrapped_consumer2` function. Now no double await, so no risk of
afterw
It seems inevitable that if you use await twice you risk being cancelled in
between. The solution is to only use a single await to do all the work,
like asyncio.queue does (and why not use that for your use case?). I don't
think inventing a parallel API of synchronous callbacks is a good idea --
as
