[Python-ideas] PEP 530: Asynchronous Comprehensions

Nick Coghlan ncoghlan at gmail.com
Wed Sep 7 07:11:16 EDT 2016


On 7 September 2016 at 04:54, Sven R. Kunze <srkunze at mail.de> wrote:
> On 06.09.2016 20:37, Nick Coghlan wrote:
>> As Anthony already noted, the "async" keyword switches to the
>> asynchronous version of the iterator protocol - you use this when your
>> *iterator* needs to interact with the event loop, just as you do when
>> deciding whether or not to mark a for loop as asynchronous.
>
> Of course "async" switches to async mode. But that was not the question. I
> asked WHY that's necessary not what it does. I already noted that Python can
> detect when to make the switch without a marker. And you fail to explain
> where the issue with this point of view is.

The Python *runtime* can tell whether the result of an expression is a
normal iterator or an asynchronous iterator, but the Python *compiler*
can't.

So at compile time, it has to decide what code to emit for the four
different scenarios Anthony listed:

    # Normal comprehension, 100% synchronous and blocking
    squares = [i**i for i in range(10)]

    # Blocking/sync iterator producing awaitables which suspend before
producing a "normal" value
    results = [await result for result in submit_requests()]

    # Non-blocking/async iterator that suspends before producing "normal" values
    results = [result async for submit_requests_and_wait_for_results()]

    # Non-blocking/async iterator that suspends before producing
awaitables which suspend again before producing a "normal" value
    results = [await result async for submit_requests_asynchronously()]

And hence needs the "async" keyword to detect when it has the latter
two cases rather than the first two.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list