On Mon, Apr 06, 2020 at 10:43:11AM -0700, Guido van Rossum wrote:
> I've been toying with the idea of introducing a "match" statement
> similar to Scala's match expression by making "match" a keyword only when
> followed by an expression and a colon.)
Didn't we conclude from `as` that having context-sensitive keywords was
a bad idea?
I'm not sure that that was the conclusion. At the time the point was that we *wanted* all keywords to be reserved everywhere, an `as` was an ugly exception to that rule, which we got rid of as soon as we could -- not because it was a bad idea but because it violated a somewhat arbitrary rule.
We went through the same thing with `async` and `await`, and the experience there was worse: a lot of libraries in the very space `async def` was aimed at were using `async` as a parameter name, often in APIs, and they had to scramble to redesign their APIs and get their users to change their programs.
In retrospect I wish we had just kept `async` as a context-sensitive keyword, since it was totally doable.
(In an early version of the PEG parser, all keywords were context-sensitive, and there were only very few places in the grammar where this required us to insert negative lookaheads to make edge cases parse correctly. The rest was taken care by careful ordering of rules, e.g. the rule for `del_stmt` must be tried before the rule for `expression_stmt` since `del *x` would match the latter.)
Personally, I would not like to have to explain to newcomers why `match`
is a keyword but you can still use it as a function or variable, but not
other keywords like `raise`, `in`, `def` etc.
match expression:
match = True
What kind of newcomers do you have that they even notice that, unless you were to draw attention to it? I'm serious -- from the kind of questions I've seen in user forums, most newcomers are having a hard enough time learning more fundamental concepts and abstractions than the precise rules for reserved words.