Match variable scoping about patma

[gvanrossum]

Why is this 'rejected'? If anything it should be 'accepted' (since we have consensus) but it also needs some kind of labeling indicating that there's still work to d. Maybe a new label 'need PEP text'?

[viridia]

Well, it's already addressed in the PEP, and there was no discussion, so I wanted to mark it as resolved somehow.

[gvanrossum]

The PEP states that a name appearing in a pattern makes the name local in the scope, but it doesn't have any discussion of the alternatives. In languages with anonymous blocks each case typically is its own scope. I know at some point I wrote up why that's not a good idea for Python (tl;dr: we should follow the walrus semantics here) but I don't remember where that explanation ended up.

[viridia]

Part of the reason why it makes sense in other languages is that match is often an expression rather than a statement (or more accurately, in many functional languages there's no distinction between expressions and statements). In these languages, the "output" of the match expression is the return result of the match arm, which can be assigned to a variable at the statement level. This does require the various match arms to have compatible return values, but an argument can be made that this is good practice anyway - if one match arm returns a float and another returns a tuple, hilarity is likely to ensue.

(By "output" I mean effects of the case clause body on the local environment. Of course, some match statements have no 'output' and are only used for their side effects, e.g. a case clause containing only a call to print(), which will likely be a fairly common use case.)

Since the Python match statement doesn't have the option of returning a value, we need a different mechanism to collect the output from the case clause. There are several mechanisms available, but they all involve mutation of some sort. One of the primary ones is to say that pattern variables are scoped to the enclosing environment of the match statement, making the mutation automatic and concise.

Of course, you could always manually assign the pattern variable to a local variable in the clause body, but this is more cumbersome and requires additional code / clutter.

The downside of having the pattern variables not be scoped to the match arm is the potential for surprise: if each match arm declares a different set of pattern variables, depending on which arm is chosen you'll end up with a mix of defined and undefined local variables. This means that code subsequent to the match statement will have to be very careful about using those variables in order to avoid throwing an exception. Another form of surprise is that people who are familiar with match statements in other languages may expect that similarly-named outer-scoped variables would be shadowed rather than overwritten.

[Tobias-Kohn]

Another important aspect of limiting the scope of match variables is of course typing: although a variable name might be shared by several case clauses, it is not uncommon that their types differ from one case to another. In Python, this is clearly not an issue.

That variables that are defined in a narrow scope escape to the local scope is not unusual in Python. We observe the same with for-loops and with-statements, for example, and I think this is rarely an issue. I think, I would actually be more surprised if Python introduced a new scope for case clauses.

Moreover, your point that match statements in Python are about mutating state and not about yielding a value is quite crucial here. I read it in that a case clause will most probably want to mutate local variables of its surrounding scope. If we introduce a separate scope for case clauses, the scoping rules either become quite complex, or the code will be riddled with nonlocal statements.

[gvanrossum]

Yup. Marking as accepted. I do feel we need to explain this carefully in the PEP, since it will be scrutinized by fans of other languages.

(However, mypy can handle certain cases where a local variable acquires a different type, as long as it can prove that there's no overlap. Example:

t = 1
print(t+1)
t = 'a'
print(t.upper())

)