On Thu, Mar 5, 2015 at 9:04 AM, Gustavo Carneiro <gjcarne...@gmail.com>
wrote:

>
>
>
> On 3 March 2015 at 19:01, Gustavo Carneiro <gjcarne...@gmail.com> wrote:
>
>>
>>
>> On 2 March 2015 at 10:12, Victor Stinner <victor.stin...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> To answer Luciano's question on as_completed(), I read the source code
>>> of the function. It's not clear to me what happens on timeout.
>>>
>>>
>>> Should we abort something on timeout? The documentation doesn't
>>> explain if tasks are cancelled or if an exception is set. In the code,
>>> it's clear that the task is not touched. It's probably just a
>>> documentation issue.
>>>
>>
>> I think it should cancel the wrapped task.  I think this is what the
>> programmer will want most of the time, and in case he doesn't want it he
>> can use shield() to prevent it.
>>
>
> I wasn't very clear: I think it should cancel the still running
> uncompleted tasks AND raise an exception, both.  That would be consistent
> with the way wait_for() behaves.
>

*What* exactly should raise an exception? Note that we're speaking of:

@asyncio.generator
def blah():
    for cf in as_completed(...):
        r = yield from cf   # <---------- HERE
        <do something with r>

and what's happening is that blah is being cancelled when it is waiting for
cf at the line marked "HERE". The cancellation mechanism already works by
sending an exception (CancelledError) into the blocked task (i.e. cf, which
represents _wait_for_one() in as_completed()). This exception normally
comes right out, and that's the desired behavior here. I don't think a
different exception should be raised, unless I am missing something?

-- 
--Guido van Rossum (python.org/~guido)

Reply via email to