<div dir="ltr">On 22 November 2017 at 14:38, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wed, 22 Nov 2017 15:03:09 +0200<br>
Serhiy Storchaka <<a href="mailto:storchaka@gmail.com">storchaka@gmail.com</a>> wrote:<br>
>  From<br>
> <a href="https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions" rel="noreferrer" target="_blank">https://stackoverflow.com/<wbr>questions/45190729/<wbr>differences-between-generator-<wbr>comprehension-expressions</a>.<br>
><br>
>      g = [(yield i) for i in range(3)]<br>
><br>
> Syntactically this looks like a list comprehension, and g should be a<br>
> list, right? But actually it is a generator. This code is equivalent to<br>
> the following code:<br>
><br>
>      def _make_list(it):<br>
>          result = []<br>
>          for i in it:<br>
>              result.append(yield i)<br>
>          return result<br>
>      g = _make_list(iter(range(3)))<br>
><br>
> Due to "yield" in the expression _make_list() is not a function<br>
> returning a list, but a generator function returning a generator.<br>
><br>
> This change in semantic looks unintentional to me. It looks like leaking<br>
> an implementation detail.<br>
<br>
</span>Perhaps we can deprecate the use of "yield" in comprehensions and make<br>
it a syntax error in a couple versions?<br>
<br>
I don't see a reason for writing such code rather than the more<br>
explicit variants.  It looks really obscure, regardless of the actual<br>
semantics.<br></blockquote><div> </div><div>People actually try this (probably simply because they like comprehensions) see two mentioned Stackoverflow questions, plus there are two b.p.o. issues.</div><div>So this will be a breaking change. Second, recent PEP 530 allowed writing a similar comprehensions with `await`:</div><div><br></div><div>    async def process(funcs):</div><div>        result = [await fun() for fun in funcs]  # OK</div><div>        ...</div><div><br></div><div>Moreover, it has the semantics very similar to the proposed by Serhiy for `yield` (i.e. equivalent to for-loop without name leaking into outer scope).</div><div>Taking into account that the actual fix is not so hard, I don't think it makes sense to have all the hassles of deprecation period.</div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div><div>    <br></div></div></div></div>