David Mertz wrote: > On Mon, Nov 23, 2020 at 9:02 PM Brian Coleman [email protected] > 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 > 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. _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JLWRMQW4OX7SXJWMORHMAIWFES6OYRR7/ Code of Conduct: http://python.org/psf/codeofconduct/