Showing content from http://mail.python.org/pipermail/python-dev/attachments/20150429/fe6d90ff/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">[...]<br>
</span>Yeah, I'm coming around to the idea. For the async pseudo-keyword, I<br>
can see that the proposal only allows its use in cases that were<br>
previously entirely illegal, but I'm not yet clear on how the PEP<br>
proposes to avoid changing the meaning of the following code:<br>
<br>
  x = await(this_is_a_function_call)<br>
<br>
Unless I'm misreading the proposed grammar in the PEP (which is<br>
entirely possible), I believe PEP 492 would reinterpret that as:<br>
<br>
  x = await this_is_not_a_function_call_any_more<br></blockquote></div><br></div><div class="gmail_extra">Ah, but here's the other clever bit: it's only interpreted this way *inside* a function declared with 'async def'. Outside such functions, 'await' is not a keyword, so that grammar rule doesn't trigger. (Kind of similar to the way that the print_function __future__ disables the keyword-ness of 'print', except here it's toggled on or off depending on whether the nearest surrounding scope is 'async def' or not. The PEP could probably be clearer about this; it's all hidden in the Transition Plan section.)<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</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