5 ms·

I just read the part about the name binding and its ... totally bonkers. Sorry, but I have no other words for this: > The implementation may choose to either

I just read the part about the name binding and its ... totally bonkers. Sorry, but I have no other words for this: > The implementation may choose to either make persistent bindings for those partial matches or not. User code including a match statement should not rely on the bindings being made for a failed match, but also shouldn't assume that variables are unchanged by a failed match. 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. That's basically dynamic scoping instead of lexical scoping only inside the match blocks and only for pattern variables. Who in their right mind comes up with a design like that? That's the javascript route! I get it that proper binding would have been difficult but if language design is too difficult, you should stop and not go one like you don't care about the consequences! This decision will waste thousands of developer hours when searching bugs!

jnxx 6y ago
> 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 https://news.ycombinator.com/item?id=26086863 )
- varjag 6y ago
  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.
  - pfalcon 6y ago
    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.
raverbashing 6y ago
Funny how they accept this craziness but for the walrus operator there was endless debate Bike shedding at its worse
pfalcon 6y ago
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.
- jnxx 6y ago
  > 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.
- dragonwriter 6y ago
  > 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.
baq 6y ago
guh. another pylint rule to forbid using same names outside match clauses and inside.
- contravariant 6y ago
  You probably should do that anyway even if the scoping was local.
dragonwriter 6y ago
> 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.
- choeger 6y ago
  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.
  - dragonwriter 6y ago
    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.)

jnxx 6y ago

> 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 https://news.ycombinator.com/item?id=26086863 )

varjag 6y ago
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.
- pfalcon 6y ago
  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.

raverbashing 6y ago

Funny how they accept this craziness but for the walrus operator there was endless debate Bike shedding at its worse

pfalcon 6y ago

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.

jnxx 6y ago
> 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.
dragonwriter 6y ago
> 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.

baq 6y ago

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

contravariant 6y ago
You probably should do that anyway even if the scoping was local.

dragonwriter 6y ago

> 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.

choeger 6y ago
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.
- dragonwriter 6y ago
  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.)