On Fri, May 4, 2018 at 1:53 PM, Tim Peters <tim.peters@gmail.com> wrote:
> [Tim]
>>> ...
>>> It's no longer the case that Python avoided that entirely, since
>>> "async def", "async for", and "async with" statements were added
>>> _without_ making "async" a new reserved word.  It may require pain in
>>> the parser, but it's often doable anyway.  At this stage in Python's
>>> life, adding new _reserved_ words "should be" an extremely high bar -
>>> but adding new non-reserved keywords (like "async") should be a much
>>> lower bar.
>
> [Guido]
>> Do note that this was a temporary solution. In 3.5 we introduced this hack.
>> In 3.6, other uses of `async` and `await` became deprecated (though you'd
>> have to use `python -Wall` to get a warning). In 3.7, it's a syntax error.
>
> See my "that deserves more thought" at the start, but wrt future cases
> then ;-)  In 3.5 and 3.6, "everything just works" for everyone.  In
> 3.7 the implementation gets churned again, to go out of its way to
> break the handful of code using "async" as an identifier.  It's
> obvious who that hurts, but who does that really benefit?
>
> My experience with Fortran convinces me nobody would _actually_ be
> confused even if they wrote code like:
>
> async def frobnicate(async=True):
>     if async:
>         async with ...

IIUC, Javascript has also gone all-in on contextual keywords. The
realities of browser deployment mean they simply cannot have flag days
or break old code, ever, meaning that contextual keywords are really
the only kind they can add at all. So their async/await uses the same
kind of trick that Python 3.5 did, and I believe they plan to keep it
that way forever.

FWIW.

-n

--
Nathaniel J. Smith -- https://vorpus.org