Re: [Python-ideas] PEP 530: Asynchronous Comprehensions
Hello, will await be allowed also in the "if" part of comprehensions? And what about the "in" part? (e.g. if I'm not mistaken, we may have an asynchronous function returning an asynchronous iterator.) Regards, Adam Bartoš
On Tue, Sep 6, 2016 at 10:42 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Yes, awaits will be allowed. I'll update the PEP.
Hasn't happened yet... I see this PEP as written in a bit of haste and very close to the 3.6b1 feature freeze (coming weekend). Usually I wouldn't accept such a hasty PEP, but the ideas in it seem pretty uncontroversial, and in line with the existing expectations for async/await. Yury, if you manage to get a working implementation signed off by one other core dev (not me) I can accept the PEP provisionally, under the same conditions as PEP 525. -- --Guido van Rossum (python.org/~guido)
On Wed, Sep 7, 2016 at 9:34 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Thank you for accepting the PEP! Will focus on the implementation now.
You're welcome! Good luck with the implementation. @Nick, regarding the suggestion to use [<expr> for <var> in async <iterable>] instead of [<expr> async for <var> in <iterable>] I think the lack of grammaticality is actually a feature -- we don't want people to confuse `async <iterable>` with `await <iterable>`. Python has no other postfix syntax like this (unless you count f(), d[k] or x.a as postfix) so I don't think people are likely to mistake this for an 'async' postfix on <expr> rather than a prefix on 'for'. Hopefully they've seen an 'async for' statement before they encounter an async comprehension. -- --Guido van Rossum (python.org/~guido)
On 8 Sep 2016 02:48, "Guido van Rossum" <guido@python.org> wrote:
On Wed, Sep 7, 2016 at 9:34 AM, Yury Selivanov <yselivanov.ml@gmail.com>
wrote:
Aye, that problem occurred to me after my last post and is definitely a concern.
I also realised that the worst case outcome I can see for the PEP 492 based syntax is some folks avoiding them in favour of the statement version because they don't like how the expression version reads (ala lambda), and as worst case scenarios go, that's not a particularly worrying one :) Cheers, Nick.
On Tue, Sep 6, 2016 at 10:42 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Yes, awaits will be allowed. I'll update the PEP.
Hasn't happened yet... I see this PEP as written in a bit of haste and very close to the 3.6b1 feature freeze (coming weekend). Usually I wouldn't accept such a hasty PEP, but the ideas in it seem pretty uncontroversial, and in line with the existing expectations for async/await. Yury, if you manage to get a working implementation signed off by one other core dev (not me) I can accept the PEP provisionally, under the same conditions as PEP 525. -- --Guido van Rossum (python.org/~guido)
On Wed, Sep 7, 2016 at 9:34 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Thank you for accepting the PEP! Will focus on the implementation now.
You're welcome! Good luck with the implementation. @Nick, regarding the suggestion to use [<expr> for <var> in async <iterable>] instead of [<expr> async for <var> in <iterable>] I think the lack of grammaticality is actually a feature -- we don't want people to confuse `async <iterable>` with `await <iterable>`. Python has no other postfix syntax like this (unless you count f(), d[k] or x.a as postfix) so I don't think people are likely to mistake this for an 'async' postfix on <expr> rather than a prefix on 'for'. Hopefully they've seen an 'async for' statement before they encounter an async comprehension. -- --Guido van Rossum (python.org/~guido)
On 8 Sep 2016 02:48, "Guido van Rossum" <guido@python.org> wrote:
On Wed, Sep 7, 2016 at 9:34 AM, Yury Selivanov <yselivanov.ml@gmail.com>
wrote:
Aye, that problem occurred to me after my last post and is definitely a concern.
I also realised that the worst case outcome I can see for the PEP 492 based syntax is some folks avoiding them in favour of the statement version because they don't like how the expression version reads (ala lambda), and as worst case scenarios go, that's not a particularly worrying one :) Cheers, Nick.
participants (4)
-
Adam Bartoš -
Guido van Rossum -
Nick Coghlan -
Yury Selivanov