Hi Ivan, On 2016-09-05 3:57 PM, Ivan Levkivskyi wrote:
On 4 September 2016 at 01:31, Yury Selivanov
mailto: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?
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:
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)]
[(yield from range(3)) for i in range(3)] 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