[Python-Dev] PEP 492 quibble and request (original) (raw)

Guido van Rossum guido at python.org
Thu Apr 30 05:21:59 CEST 2015

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 <ncoghlan at gmail.com> 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(thisisafunctioncall) >> >> Unless I'm misreading the proposed grammar in the PEP (which is >> entirely possible), I believe PEP 492 would reinterpret that as: >> >> x = await thisisnotafunctioncallanymore > > > 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 printfunction 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 " 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 asyncfunctions" 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 at gmail.com | Brisbane, Australia

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150429/bf0a69f6/attachment-0001.html>

More information about the Python-Dev mailing list