On 30 April 2015 at 12:31, Guido van Rossum
On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan
wrote: [...] Yeah, I'm coming around to the idea. For the async pseudo-keyword, I can see that the proposal only allows its use in cases that were previously entirely illegal, but I'm not yet clear on how the PEP proposes to avoid changing the meaning of the following code:
x = await(this_is_a_function_call)
Unless I'm misreading the proposed grammar in the PEP (which is entirely possible), I believe PEP 492 would reinterpret that as:
x = await this_is_not_a_function_call_any_more
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.)
Ah, nice, although even reading the Transition Plan section didn't clue me in to that particular aspect of the idea :) Given that clarification, I think the rationale for "no __future__ statement needed" can be strengthened by focusing on the fact that such a statement would largely be *redundant*, given that: * "async def", "async with", and "async for" are all currently syntax errors, and hence adding them is backwards compatible if "async" is otherwise treated as a normal variable name * "await <expr>" only gains its new interpretation when used inside an "async def" statement, so "async def" fills the role that a module level compiler declaration like "from __future__ import async_functions" would otherwise fill That said, it may be worth having the future statement *anyway* as: 1. It gives us the runtime accessible record of the feature transition in the __future__ module 2. It lets folks opt-in to the full keyword implementation from day 1 if they prefer, addressing the tokenisation limitation noted in the PEP: https://www.python.org/dev/peps/pep-0492/#transition-period-shortcomings Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia