Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171124/f81e3135/attachment.html below:
<div dir="ltr">OK, so my 24 hours are over :-)<br><div><br><br>On 24 November 2017 at 01:50, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 November 2017 at 23:04, Ivan Levkivskyi <span dir="ltr"><<a href="mailto:levkivskyi@gmail.com" target="_blank">levkivskyi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">I don't see why this particular case qualifies for such a radical measure as an exception to syntactic rules,</div><div class="gmail_extra">instead of just fixing it (sorry Nick :-)</div></div></blockquote><div><br></div>I've posted in more detail about this to the issue tracker, but the argument here is: because making it behave differently from the way it does now while still hiding the loop iteration variable potentially requires even more radical revisions to the lexical scoping rules :)</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">If somebody can come up with a clever trick to allow yield inside a comprehension to jump levels in a relatively intuitive way, that would actually be genuinely cool, but the lexical scoping rules mean it's trickier than it sounds.</div></div></div></blockquote><div><br></div><div>"potentially" is the key word here. The plan is to avoid "more radical revisions".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Now that I frame the question that way, though, I'm also remembering that we didn't have "yield from" yet when I wrote the current comprehension implementation, and given that, it may be as simple as having an explicit yield expression in a comprehension imply delegation to a subgenerator.</div></div></div></blockquote><div><br></div><div>My understanding is that this is exactly how async comprehensions are currently implemented and why they work as one would naively expect, i.e. `await` is "bound" to the surrounding async def, not to the implicit scope async def. So that an async comprehension is just equivalent to a for-loop. However, although "implicit yield from" solution is simpler than the one proposed by Serhiy, I still more like the latter one. The former has its strange cases, for example I mentioned before in this thread:</div><div><br></div><div>>>> async def f():<br>...    for i in range(3):<br>...        yield i<br>... <br>>>> async def g():<br>...    return [(yield i) async for i in f()]<br>... <br>>>> g().send(None)<span class="gmail-im"><br>Traceback (most recent call last):<br> File "<stdin>", line 1, in <module><br></span> File "<stdin>", line 2, in g<br>TypeError: object async_generator can't be used in 'await' expression</div><div><br></div><div>My understanding is that the strange error is exactly because of the implicit `yield from`. With Serhiy's approach this would work.</div><div>Another minor bonus of Serhiy's idea is a performance gain: we will not push an execution frame.</div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div></div></div></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4