3 ms·

In true Python style, the variable captures will no doubt use assignment rather than creating a new scope, and will lead to all sorts of wonderful and hidden bu

In true Python style, the variable captures will no doubt use assignment rather than creating a new scope, and will lead to all sorts of wonderful and hidden bugs. Regardless? Is there some protocol to allow user defined classes to be matched? One of the situations with algebraic datatypes is that it's very clearly defined what can and cannot be matched so that nothing is special and built in, but it also requires that concepts that should honestly be private be exposed. — it would perhaps be better to have some kind of protocol whereby some sort of “match object”is returnen for this functionality.

iamevn 6y ago
The assignments use the usual goofy python scoping rules and implementations are allowed to make this a footgun. Consider this (contrived for the sake of simplicity) example: for x in input: backup = x point = f(x) match point: case Point(x = 6, y = 9): print('found a nice point') case _: print('not nice point') assert x == backup # this may fail The first case is allowed to bind x if point.x == 6 even if point.y != 9 and the case fails. Reassigning x in the surrounding scope is annoying but expected in python. Reassigning even when the case fails is not at all expected imo. https://www.python.org/dev/peps/pep-0634/#match-semantics https://www.python.org/dev/peps/pep-0634/#match-semantics > During failed pattern matches, some subpatterns may succeed. For example, while matching the pattern (0, x, 1) with the value [0, 1, 2], the subpattern x may succeed if the list elements are matched from left to right. 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.

iamevn 6y ago

The assignments use the usual goofy python scoping rules and implementations are allowed to make this a footgun. Consider this (contrived for the sake of simplicity) example: for x in input: backup = x point = f(x) match point: case Point(x = 6, y = 9): print('found a nice point') case _: print('not nice point') assert x == backup # this may fail The first case is allowed to bind x if point.x == 6 even if point.y != 9 and the case fails. Reassigning x in the surrounding scope is annoying but expected in python. Reassigning even when the case fails is not at all expected imo. https://www.python.org/dev/peps/pep-0634/#match-semantics https://www.python.org/dev/peps/pep-0634/#match-semantics > During failed pattern matches, some subpatterns may succeed. For example, while matching the pattern (0, x, 1) with the value [0, 1, 2], the subpattern x may succeed if the list elements are matched from left to right. 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.