David Mertz wrote:
Basically, I agree matching/destructuring is a powerful idea. But I also wonder how much genuinely better it is than a library that does not require a language change. For example, I could create a library to allow this: m = Matcher(arbitrary_expression) if m.case("StringNode(s)"): process_string(m.val.s) elif m.case("[a, 5, 6, b]"): process_two_free_vars(m.val.a, m.val.b) What you are proposing here is very similar in effect to executing pattern matching statements using eval. What is the advantage of implementing the pattern matching functionality in a library if the user interface for that functionality has the same pitfalls as eval? I don't understand the similarity with eval that you are suggesting. My hypothetical library would store the value passed as initializer to Matcher, and provide a method .case(). That method would need to do some moderately complicated parsing of the pattern passed into it, but using parsing techniques, not any eval() call. Btw. I modified my above strawman just slightly to what might be a bit better API. If there are any free variables in the pattern, they would be provided by
On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman brianfcoleman@gmail.com wrote: the Matcher object. For example, they could be attributes of the property m.val. Or I suppose we could make them attributes of the Matcher object itself, e.g. m.a and m.b, but I think name conflicts with e.g. m.case. Anyway, it's a strawman not an API design. If the pattern looked kinda like a class constructor (i.e. exactly the same as PEP 634 rules), the .case() method would do an isinstance() check before doing its other stuff. If the pattern looks like a list, it would scan the freevars inside it and match the constant values. And so on. The actual return value from .m.case(...) would be True or False (or at least something truthy or falsy). However, it MIGHT create some new attributes (or keys, or something else) on the Matcher object if the pattern actually matched. I agree the above is slightly less readable than PEP 635 syntax, but it seems to have the entire power of the proposal without changing Python syntax.
To be more precise, the similarity that I see to `eval` is that syntax errors in the patterns that are passed to the `case` method cannot be detected at compile time and instead will be detected at runtime. Building the syntax into the language gives the advantage of producing a syntax error at compile time. It also makes it easier for linters and type checkers to validate the pattern matching clauses if the syntax is built into the language.