[Python-ideas] PEP 530: Asynchronous Comprehensions

[Yury Selivanov]

Hi Ivan,


On 2016-09-05 3:57 PM, Ivan Levkivskyi wrote:
> On 4 September 2016 at 01:31, Yury Selivanov <yselivanov.ml at gmail.com 
> <mailto:yselivanov.ml at gmail.com>> wrote:
>
>     Below is a proposal to add support for asynchronous comprehensions and
>     asynchronous generator expressions in Python 3.6.
>
>
> Interesting proposal. Would be nice to have this!
>
> I have one question:
>
>     ``await`` in Comprehensions
>     ---------------------------
>
>     We propose to allow the use of ``await`` expressions in both
>     asynchronous and synchronous comprehensions::
>
>         result = [await fun() for fun in funcs]
>         result = {await fun() for fun in funcs}
>         result = {fun: await fun() for fun in funcs}
>
>         result = [await fun() async for fun in funcs]
>         result = {await fun() async for fun in funcs}
>         result = {fun: await fun() async for fun in funcs}
>
>     This is only valid in ``async def`` function body.
>
>
> Do I understand correctly that the limitation that they are allowed
> only in async def is because await binds to the enclosing coroutine?

Correct.
>
> There is an old "bug" (some people call this a feature) 
> http://bugs.python.org/issue10544
> If one uses yield in a comprehension, then it leads to unexpected results:
>
> >>> def f():
> ...     yield
> ...     res = [(yield) for i in range(3)]
> ...     return res
> ...
> >>> fg = f()
> >>> next(fg)
> >>> next(fg)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> StopIteration: <generator object f.<locals>.<listcomp> at 0x7fe05b37a498>
>
> This function yields only once and then returns another generator.
> This is because the yield in comprehension "lives" in an auxiliary 
> function
> scope used to make the comprehension. So that such comprehension
> are even allowed outside function body:
>
> >>> [(yield) for i in range(3)]
> <generator object <listcomp> at 0x7fe05b3d41f0>
> >>> [(yield from range(3)) for i in range(3)]
> <generator object <listcomp> at 0x7fe05ade11f0>
>
> Do I understand correctly that this is not the case with
> asynchronous comprehensions?
>
> If this is not the case, then I like this, but this will be 
> inconsistent with
> normal comprehensions.

I'm not sure what will happen here. Will have an update once a reference 
implementation is ready.  Seems that the bug you're referring to is 
something that should be just fixed.

Yury