[Python-Dev] PEP 492 quibble and request

[Yury Selivanov]

On 2015-04-29 11:01 PM, Nick Coghlan wrote:
> On 30 April 2015 at 12:31, Guido van Rossum<guido at python.org>  wrote:
>> >On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan<ncoghlan at gmail.com>  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

Thanks, Nick.

I've fixed the Transition Plan section, and rewrote the
"why not __future__" one too.

https://hg.python.org/peps/rev/552773d7e085
https://hg.python.org/peps/rev/5db3ad3d540b

Yury