[Python-Dev] Tricky way of of creating a generator via a comprehension expression

David Mertz mertz at gnosis.cx
Sat Nov 25 16:05:39 EST 2017

FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real
code. Probably 80% of those would be fine with yield statements, but a
significant fraction use `gen.send()`.

On the other hand, I have yet once to use 'await', or 'async' outside of
pedagogical contexts. There are a whole lot of generators, including ones
utilizing state injection, that are useful without the scaffolding of an
event loop, in synchronous code.

Of course, I never use them in comprehensions or generator expressions. And
even after reading every post in this thread, the behavior (either existing
or desired by some) such constructs have is murky and difficult for me to
reason about. I strongly support deprecation or even just immediate
SyntaxError in 3.7.

On Nov 25, 2017 12:38 PM, "Guido van Rossum" <guido at python.org> wrote:

> On Sat, Nov 25, 2017 at 12:17 PM Brett Cannon <brett at python.org> wrote:
> On Fri, Nov 24, 2017, 19:32 Guido van Rossum, <guido at python.org> wrote:
>>>> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum <guido at python.org>
>>>> wrote:
>>>>> The more I hear about this topic, the more I think that `await`,
>>>>> `yield` and `yield from` should all be banned from occurring in all
>>>>> comprehensions and generator expressions. That's not much different from
>>>>> disallowing `return` or `break`.
>>>> From the responses it seems that I tried to simplify things too far.
>>>> Let's say that `await` in comprehensions is fine, as long as that
>>>> comprehension is contained in an `async def`. While we *could* save `yield
>>>> [from]` in comprehensions, I still see it as mostly a source of confusion,
>>>> and the fact that the presence of `yield [from]` *implicitly* makes the
>>>> surrounding `def` a generator makes things worse. It just requires too many
>>>> mental contortions to figure out what it does.
>>>> I still propose to rule out all of the above from generator
>>>> expressions, because those can escape from the surrounding scope.
>>> +1 from me
> On Sat, Nov 25, 2017 at 9:21 AM, Yury Selivanov <yselivanov.ml at gmail.com>
> wrote:
>> So we are keeping asynchronous generator expressions as long as they are
>> defined in an 'async def' coroutine?
> I would be happy to declare that `await` is out of scope for this thread.
> It seems that it is always well-defined and sensible what it does in
> comprehensions and in genexprs. (Although I can't help noticing that PEP
> 530 does not appear to propose `await` in generator expressions -- it
> proposes `async for` in comprehensions and in genexprs, and `await` in
> comprehensions only -- but they appear to be accepted nevertheless.)
> So we're back to the original issue, which is that `yield` inside a
> comprehension accidentally makes it become a generator rather than a list,
> set or dict. I believe that this can be fixed. But I don't believe we
> should fix it. I believe we should ban `yield` from comprehensions and from
> genexprs. We don't need it, and it's confused most everyone. And the ban
> should extend to `yield from` in those same contexts. I think we have a
> hope for consensus on this.
> (I also think that if we had invented `await` earlier we wouldn't have
> gone down the path of `yield` expressions -- but historically it appears we
> wouldn't have invented `await` at all if we hadn't first tried `yield` and
> then `yield from` to build coroutines, so I don't think this so bad after
> all. :-)
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mertz%40gnosis.cx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171125/b8670fb0/attachment-0001.html>

More information about the Python-Dev mailing list