RetroSearch Browse

Thu Apr 30 04:07:24 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-April/139674.html

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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2015-April/139674.html below:

[Python-Dev] PEP 492 quibble and request