On 4 September 2016 at 01:31, Yury Selivanov <yselivanov.ml@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?

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.

--

Ivan