[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