Belt and suspenders. :-) We may need help with the implementation though -- PEP 479 is still waiting on implementation help with __future__ too AFAIK.
On Wed, Apr 29, 2015 at 8:01 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 30 April 2015 at 12:31, Guido van Rossum <gu...@python.org> wrote: > > On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan <ncogh...@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 > > 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 | ncogh...@gmail.com | Brisbane, Australia > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com