Hacker News Reader

> This part of the behavior is left intentionally unspecified so different implementations can add optimizations, and to prevent introducing semantic restrictions that could limit the extensibility of this feature.

Isn't this more or less what was the argument to allow more undefined behaviour in ANSI C ?

(Edit: I think this also comes from the tension caused by integrating features from functional languages into an imperative language, like explained in more detail here: https://news.ycombinator.com/item?id=26086863 )

Unlike Python, C has the excuse of runtime efficiency as a plausible rationale.

Python is big time SLOW, there's a ton of untapped optimisation potential before wandering into UB for sake of speed territory.

They went for "UB" exactly because they understand the current behavior is not ideal, and to allow for better implementation and to change it later.

No worries, this was debated fiercely. In the end, we had to choose between "Python has a reference syntax for pattern matching" vs "Python continues to have disparate 3rd-party extensions for pattern matching, without clear leader".

The essence of the issue you quote is that Python needs block-level scope for variables (in addition to the standard function-level scope). Similar to what JavaScript acquired with "let" and "const" keywords. That's more pervasive issue than just "match" statement of pattern matching, and thus better handled orthogonally to it.

> The essence of the issue you quote is that Python needs block-level scope for variables

In this case, would it not better to fix block scoping first, and introduce the pattern matching feature later?

Also, this is by far not a easily agreeable issue because changing this will break a lot of ugly but working imperative code. This has easily more impact than changing the default string type to Unicode.

For me, adding pattern matching before defining scoping feels like a technical debt issue in a large code base - if you make a change that depends on an improvement, it is much cleaner to make that improvement first.

Also, Python has only one widely-used implementation, and arguably it will be difficult to change behavior of that implementation if people did came to rely on a certain scoping behavior.

> The essence of the issue you quote is that Python needs block-level scope for variables (in addition to the standard function-level scope).

No, it's not. I mean, sure, either general or special-case (like comprehensions already provide, and there is no good reason for matches not to) isolated scope would solve this, but so would bind-on-success-only with existing scoping.

> That's basically dynamic scoping instead of lexical scoping

No, it's not a scoping change, the variable in the pattern is definitively in the scope (function or module) containing the pattern match.

It's just non-determinism (or, no specification) as to what, if anything, gets assigned to it as a result of the failed pattern match.

It is. Normally, a match expression can bind variables to values. In lexical scoping, these variables exist inside the match expression. In dynamic scoping they exist outside. The design mistake seems to be to assume that the patterns inside a match expression should be regular expressions, whereas pattern expressions should be a dedicated syntactic category.

Python has lexical scoping in which modules, functions, and comprehensions are the only lexical units that introduce a new scope. The addition of pattern matching, and the UB around whether binding happens for failed matches, do not change that to dynamic scope, in which the course of execution, not the lexical structure, would determine visibility (e.g., variables would be visible in a function called from, even if not nested within, the one in which they were defined.)

guh.

another pylint rule to forbid using same names outside match clauses and inside.

You probably should do that anyway even if the scoping was local.

Funny how they accept this craziness but for the walrus operator there was endless debate

Bike shedding at its worse