<div dir="ltr"><div>Belt and suspenders. :-)<br><br></div>We may need help with the implementation though -- PEP 479 is still waiting on implementation help with __future__ too AFAIK.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 29, 2015 at 8:01 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"><div class="HOEnZb"><div class="h5">On 30 April 2015 at 12:31, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> [...]<br>
>> 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>
><br>
><br>
> Ah, but here's the other clever bit: it's only interpreted this way *inside*<br>
> a function declared with 'async def'. Outside such functions, 'await' is not<br>
> a keyword, so that grammar rule doesn't trigger. (Kind of similar to the way<br>
> that the print_function __future__ disables the keyword-ness of 'print',<br>
> except here it's toggled on or off depending on whether the nearest<br>
> surrounding scope is 'async def' or not. The PEP could probably be clearer<br>
> about this; it's all hidden in the Transition Plan section.)<br>
<br>
</div></div>Ah, nice, although even reading the Transition Plan section didn't<br>
clue me in to that particular aspect of the idea :)<br>
<br>
Given that clarification, I think the rationale for "no __future__<br>
statement needed" can be strengthened by focusing on the fact that<br>
such a statement would largely be *redundant*, given that:<br>
<br>
* "async def", "async with", and "async for" are all currently syntax<br>
errors, and hence adding them is backwards compatible if "async" is<br>
otherwise treated as a normal variable name<br>
* "await <expr>" only gains its new interpretation when used inside an<br>
"async def" statement, so "async def" fills the role that a module<br>
level compiler declaration like "from __future__ import<br>
async_functions" would otherwise fill<br>
<br>
That said, it may be worth having the future statement *anyway* as:<br>
<br>
1. It gives us the runtime accessible record of the feature transition<br>
in the __future__ module<br>
2. It lets folks opt-in to the full keyword implementation from day 1<br>
if they prefer, addressing the tokenisation limitation noted in the<br>
PEP: <a href="https://www.python.org/dev/peps/pep-0492/#transition-period-shortcomings" target="_blank">https://www.python.org/dev/peps/pep-0492/#transition-period-shortcomings</a><br>
<br>
Regards,<br>
<div class="HOEnZb"><div class="h5">Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>