replacing `else` with `then` in `for` and `try`

[Chris Angelico]

On Thu, Nov 2, 2017 at 12:42 PM, bartc <bc at freeuk.com> wrote:
> But if people prefer a different keyword, then why not? I think 'then' can
> be used, without impacting its use as an identifier, because it will always
> be followed by ":". Of course you would need to allow both "else" and "then"
> for backwards compatibility.

No, it can't. Contextually-sensitive keywords are a road to major
confusion. It's been done before, but usually (always?) as a migration
plan towards full keyword status; most recently, 'async' and 'await'
were brought in that way:

Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async def foo():
...  pass
...
>>> async = 1
>>>


Python 3.7.0a2+ (heads/master:4f469c0966, Nov  2 2017, 18:04:12)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async def foo():
...  pass
...
>>> async = 1
  File "<stdin>", line 1
    async = 1
          ^
SyntaxError: invalid syntax

>From Python 3.4 to Python 3.7, async changes from being an identifier
to being a keyword. The only reason it's a "soft keyword" for 3.5 and
3.6 is for the sake of transition - it's not a means of avoiding the
costs of keyword creation. The proposal for async functions had to
justify the creation of two keywords.

Additionally, the notion of having both "else" and "then" is even
worse: everyone has to learn BOTH keywords, and figure out when to use
each. For compatibility with older Python versions, most people will
use "else", but some will go with "then" because it's the new and
trendy option.

Ugh. I deal with this sort of thing in JavaScript. I don't want to
have it in Python too.

ChrisA