On Friday, March 31, 2023 at 5:51:33 PM UTC-7, Chris Angelico wrote:
> Can you confirm that it is indeed failing to catch the exception? Try this:
>
> except asyncio.CancelledError:
> print("Cancelled correctly")
>
> followed by the same type checking from above. Since the ID is the
> same, I
On Friday, March 31, 2023 at 4:14:51 PM UTC-7, Chris Angelico wrote:
> Okay, so that deals with the part from the subject line, leaving a
> slightly different problem: The caught exception is not of the same
> type as you were expecting. First question: Can you reproduce the
> issue on command?
On Friday, March 31, 2023 at 3:23:24 PM UTC-7, Chris Angelico wrote:
> On Sat, 1 Apr 2023 at 09:19, Clint Olsen wrote:
> > Attempting to catch asyncio.CancelledError or asyncio.CancelledError does
> > not work. The function in question looks like:
> >>> asyncio.e
I'm having some issues with task cancellation inside a signal handler. My tasks
do get cancelled, but I see odd behavior:
Traceback (most recent call last):
File
"/home/utils/release/sw/tools/python-3.9.7/lib/python3.9/site-packages/grpc/aio/_call.py",
line 406, in _consume_request_iterator
On Monday, March 13, 2023 at 11:32:23 PM UTC-7, Clint Olsen wrote:
> We have an application that involves submitting hundreds to thousands of jobs
> to a shared computing resource, and we're using asyncio to do so because it
> is far less overhead than threading or multiproc
On Monday, March 13, 2023 at 11:55:22 PM UTC-7, gst wrote:
> Le mardi 14 mars 2023 à 02:32:23 UTC-4, Clint Olsen a écrit :
> I'm not asyncio expert or even not advanced user, but using a simple list to
> hold the jobs to execute and fill it as necessary after results gathering
We have an application that involves submitting hundreds to thousands of jobs
to a shared computing resource, and we're using asyncio to do so because it is
far less overhead than threading or multiprocessing for the bookkeeping
required to keep track of all these jobs. It makes extensive use of
