[Python-Dev] PEP 492 quibble and request (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Thu Apr 30 05:01:40 CEST 2015
- Previous message (by thread): [Python-Dev] PEP 492 quibble and request
- Next message (by thread): [Python-Dev] PEP 492 quibble and request
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 async_functions" would otherwise fill
That said, it may be worth having the future statement anyway as:
- It gives us the runtime accessible record of the feature transition in the future module
- 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
- Previous message (by thread): [Python-Dev] PEP 492 quibble and request
- Next message (by thread): [Python-Dev] PEP 492 quibble and request
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]