Is Python piling in too many new features taken from other languages? Is Pattern Matching yet another way of doing things for a language which has prided itself on there being one obvious way of doing things? In short, is Python being ruined by people who don’t appreciate the benefits of Less Is More?<\/p>\n\n\n\n
Short answer: No ;-). Long answer: see below. Changed answer: see Second Impressions of Python Pattern Matching<\/a><\/p>\n\n\n\n I appreciate arguments for simplicity, and I want the bar for new features to be high, but I am glad Pattern Matching made its way in. It will be the One Obvious Way for doing, errr, pattern matching. Pattern matching may not be as crucial in a dynamically typed language like Python but it is still useful. And the syntax is nice too. Not having used pattern matching before in other languages I wasn’t quite sure how to think about it. According to Tom\u00e1\u0161 Karabela I’ve been using something similar without realising it (Python 3.10 Pattern Matching in Action<\/a>). But what is Pattern Matching? And why would I use it in Python?<\/p>\n\n\n\n I have found it useful to think of Pattern Matching as a Switch statement on steroids.<\/p>\n\n\n\n Pattern Matching is a Switch Statement on Steroids<\/p><\/blockquote>\n\n\n\n The switch aspect is the way the code passes through various expressions until it matches. That makes total sense – one of the earliest things we need to do in programming is respond according the value \/ nature of something. Even SQL has The steroids aspect has two parts:<\/p>\n\n\n\n Unpacking is beautiful and elegant so it is a real pleasure to find it built into Python’s Pattern Matching. Duck typing can be a wonderful thing but sometimes it is useful to match on type. Sometimes you think exactly the same as the language feature, sometimes not. Here are some mistakes I made straight away. Typically they were caused by a basic misunderstanding of how Pattern Matching “thinks”.<\/p>\n\n\n\n Patterns Ain’t Objects<\/p><\/blockquote>\n\n\n\n If we forget we get a TypeError:<\/p>\n\n\n\n Note, you must match the parameter names (the left side) but can unpack to any variable names you like (the right side). It may feel a bit odd being forced to use what feel like keyword arguments when the original class definition is positional but we must remember that we aren’t making an object – we are designing a pattern and collecting variables \/ names.<\/p>\n\n\n\n This might become a common error because of our experience with case Patterns have to be Patterns<\/p><\/blockquote>\n\n\n\n Instead, using the example of integer patterns, we need It is very common in switch \/ case when statements to have conditions. Sometimes it is the whole point of the construct – we supply one value and respond differently according to its values \/ attributes. E.g. in rough pseudocode if temp < 0 freezing, if > 100 boiling, otherwise normal. In Pattern Matching value conditions are secondary. We match on a pattern first and then, perhaps evaluating the unpacked variables in an expression, we apply a guard condition.<\/p>\n\n\n\n Depending on how it’s used we could think of “Pattern Matching” as “Pattern and Guard Condition Matching”.<\/p>\n\n\n\n The most similar to a classic switch construct would be:<\/p>\n\n\n\n One final thought: there seems to be nothing special about the “default” option (using switch language) – namely, Make image using Dockerfile e.g. the following based on Install Python3 in Ubuntu Docker<\/a> (I added vim and a newer Ubuntu image plus changed apt-get to apt (even though it allegedly has an unstable cli interface):<\/p>\n\n\n\n (don’t forget the dot at the end – that’s a reference to the path to find Dockerfile)<\/p>\n\n\n\n Then make container:<\/p>\n\n\n\n and run it with access to bash command line<\/p>\n\n\n\n Pattern matching tutorial for Pythonic code | Pydon’t<\/a><\/p>\n\n\n\n Python 3.10 Pattern Matching in Action<\/a><\/p>\n\n\n\n PEP 622<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Controversy – Python Adding Everything But the Kitchen Sink? Is Python piling in too many new features taken from other languages? Is Pattern Matching yet another way of doing things for a language which has prided itself on there being … Continue reading match<\/code> and case<\/code> are pretty self-explanatory. Of course, there are some gotchas to watch out for but pattern matching is arguably one of the most interesting additions to Python since f-strings in Python 3.6. So let’s have a look and see what we can do with it.<\/p>\n\n\n\nWhat is Pattern Matching?<\/h2>\n\n\n\n
CASE WHEN<\/code> statements.<\/p>\n\n\n\nUnpacking<\/h3>\n\n\n\n
case (x, y):<\/code> looks for a two-tuple and unpacks into x<\/code> and y<\/code> names ready to use in the code under the case condition. case str(x):<\/code> looks for a string and assigns the name x<\/code> to it. Handy.<\/p>\n\n\n\nType Matching<\/h3>\n\n\n\n
case Point(x=x, y=y):<\/code> only matches if an instance of the Point<\/code> class. case int(x):<\/code> only matches if an integer. Note – case Point(x, y): doesn’t work in a case condition because positional sub-patterns aren’t allowed. Confused? More detail on possible gotchas below:<\/p>\n\n\n\nGotchas<\/h2>\n\n\n\n
Patterns aren’t Objects<\/h3>\n\n\n\n
case Point(x, y):<\/code> seems to me to be an obvious way of looking for a Point<\/code> object and unpacking its values into x<\/code> and y<\/code> but it isn’t allowed. It is the correct syntax for instantiating a Point<\/code> object but we are not instantiating an object and supplying the object the case condition – instead we are supply a pattern to be matched and unpacked. We have to have a firm grasp on the notion that Python patterns are not objects.<\/p>\n\n\n\ncase Point(0, 999):
TypeError: Point() accepts 0 positional sub-patterns (2 given)<\/code><\/p>\n\n\n\ncase Point(x=0, y=y):<\/code> the x=<\/code> and y=<\/code> are the required syntax for a pattern. We insist on x<\/code> being 0<\/code> but y<\/code> can be anything (which we add the name y<\/code> to). We could equally have written case Point(x=0, y=y_val):<\/code> or case Point(x=0, y=spam):<\/code>.<\/p>\n\n\n\ncase Point:<\/code>, case int:<\/code>, case str:<\/code>, case float:<\/code> don’t work as you might expect. They match anything and assign it to the name Point<\/code> or int<\/code> or str<\/code> etc. Definitely NOT what you want. The only protection is when you accidentally do this before other case conditions – e.g.<\/p>\n\n\n\ncase int:
^
SyntaxError: name capture 'int' makes remaining patterns unreachable<\/code><\/p>\n\n\n\nisinstance<\/code> where we supply the type e.g. isinstance(x, int)<\/code>. Remember:<\/p>\n\n\n\ncase int():<\/code>, or, if we want to “capture” the value into, say, x<\/code>, case int(x):<\/code>.<\/p>\n\n\n\nGuards and Traditional Switch Statements<\/h2>\n\n\n\n
case float(x) if abs(x) < 100:
...
case float(x) if abs(x) < 200:
etc<\/code><\/p>\n\n\n\nmatch:<\/code>
case val if val < 10:
...
case val if val < 20:
...
etc<\/code><\/p>\n\n\n\ncase _:<\/code>. It merely captures anything that hasn’t already been matched and puts _<\/code> as the name i.e. it is a throwaway variable. We could capture and use that value with a normal variable name although that is optional because there’s nothing stopping us from referencing the original name fed into match. But, for example, case mopup:<\/code> would work.<\/p>\n\n\n\nHow to play with it on Linux<\/h2>\n\n\n\n
FROM ubuntu:20.04<\/code><\/p>\n\n\n\nRUN apt update && apt install -y software-properties-common gcc && \\
add-apt-repository -y ppa:deadsnakes\/ppa<\/code><\/p>\n\n\n\nRUN apt update && apt install -y python3.10 python3-distutils python3-pip python3-apt vim<\/code><\/p>\n\n\n\ndocker build --tag pyexp .<\/code><\/p>\n\n\n\ndocker create --name pyexp_cont pyexp<\/code><\/p>\n\n\n\ndocker container run -it pyexp \/bin\/bash<\/code><\/p>\n\n\n\nUseful Links<\/h2>\n\n\n\n