> On Jan 1, 2020, at 08:32, Guido van Rossum <gu...@python.org> wrote: > > Here's a proposal for JavaScript that seems to be going through > standardization: https://github.com/tc39/proposal-pattern-matching
The JS solution is interesting, but I’m not sure how well it works for a different language. Python is closer to JS than, say, Scala or Rust are, but it’s still different. The innovation that possibly applies to Python is that you don’t actually need destructuring in a dynamic language. When you discover that a Notification is an Email, you can just access the email attributes (and even methods) in the Notification, so there’s no need to pull them out into separate variables or to “downcast” the Notification to an Email with an as clause. The one that probably doesn’t is that if everything is an object and objects are just dicts of their attributes, you can spell pattern matching as a dict comparison, effectively `all(pattern.get(key, undefined) == match.get(key, undefined) for key in pattern)`. While you can simulate that in Python (with getattr, etc.) I don’t think it’s as natural. If someone else wants to work through that in more detail and try to come up with a JS-inspired proposal for Python, it might turn out very cool. But I think it would be pretty different from the tack I’m taking. > Here's the end of an older python-ideas thread: > https://mail.python.org/archives/search?mlist=python-ideas%40python.org&q=pattern+matching+reprise His section on Orthogonality is key here: > I feel that this dilemma is one of the core issues why the syntax of > switch statements, or pattern matching seems so exceptionally hard. > > In the end, it might therefore, indeed, make more sense to find a > structure that is more in line with if/elif/else-chains. This would > lead to a form of pattern matching with little support for > switch statement, though. The dilemma he’s referring to is that a switch/case (or case/of or match/when etc.) doesn’t fit into the Python statement model properly. So, what would we lose by having “little support for switch statement”? I think usually nothing. The reason it’s necessary in other languages is to preprocess and scope the match, which isn’t relevant to Python. If you need to preprocess a value in some way before passing it to all of the patterns, you can just do that in a separate statement above them; it’s still in the right scope. If you want block structure anyway, you can do that with a with statement (and that also gives you a place to hook exit for features like ensuring that you didn’t fall off the end, if you want that), but that can be optional. So, can we come up with a structure that’s more in line with if/elif? Unlike C switch statements, pattern matching does actually need something more than Python if/elif already provides, but I think extending if/elif rather than coming up with a whole new parallel structure might suffice. So I’m trying to find the simplest extension to if/elif that could work. The key inspiration comes from Scala and other languages building pattern matching structures out of a “match primitive” instead of the traditional solution (taken to its extreme in Haskell) of building the most complex and flexible structure and then designing everything else in terms of how it syntactically translates to that structure. Iterable unpacking is already part of the way to that primitive, but it can’t test values while destructuring (which has already been solved in many languages), and because it raises on failure it can’t be used in an if/elif-like structure (which has already been sort of solved in Swift and Rust). I’m not sure it can be made to work with only a few smallish changes, but I’m hoping it can.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7R77H6JHSYNBPBEKJZE53JB726ZI272Q/ Code of Conduct: http://python.org/psf/codeofconduct/
