On 30 April 2015 at 11:12, Guido van Rossum email@example.com wrote:
On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan firstname.lastname@example.org wrote:
It is also makes things more painful than they need to be for syntax highlighters.
Does it? Do highlighters even understand __future__ imports? I wouldn't mind if a highlighter always highlighted 'async' and 'await' as keywords even where they aren't yet -- since they will be in 3.7.
Yeah, that's a good point.
'as' went through the "not really a keyword" path, and it's a recipe for complexity in the code generation toolchain and general quirkiness as things behave in unexpected ways.
I don't recall that -- but it was a really long time ago so I may misremember (did we even have __future__ at the time?).
I don't actually know, I only know about its former pseudo-keyword status because we made it a real keyword as part of "from __future__ import with_statement".
I think I was conflating it with the hassles we encountered at various points due to None, True, and False not being real keywords in Python 2, but I don't believe the problems we had with those apply here (given that we won't be using 'await' and 'async' as values in any context that the bytecode generation chain cares about).
We have a defined process for introducing new keywords (i.e. __future__ imports) and the PEP doesn't adequately make the case for why we shouldn't use it here.
That's fair. But because of the difficulty in introducing new keywords, many proposals have been shot down or discouraged (or changed to use punctuation characters or abuse existing keywords) -- we should give Yury some credit for figuring out a way around this. Honestly I'm personally on the fence.
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