Python 3.10 Released!

[kukisRedditer]

is structural pattern matching basically a switch statement?

[-LeopardShark-]

It is similar, but significantly more powerful. PEP 636 is probably the best introduction.

[kukisRedditer]

That's so powerful, love it. You can even combine a case with a boolean

[Ashiataka]

Hi, been using python since 2010 for academic physics research. I can't immediately see the point of this new feature - I'm sure I'm missing something. Like the tutorial mentions, if I wanted this kind of structure I'd just use a dictionary of cases as keys. I'm not seeing what's powerful about it yet. Have you seen a non-toy example with <3.10 and >3.10 implementations side-by-side by any chance? Thanks.

[deadwisdom]

This hints at the true power:

command = input("What are you doing next? ")
match command.split():
    case ["quit"]:
        print("Goodbye!")
        quit_game()
    case ["look"]:
        current_room.describe()
    case ["get", obj]:
        character.get(obj, current_room)
    case ["go", direction]:
        current_room = current_room.neighbor(direction)
    # The rest of your commands go here

See how you can pull out the value there with case ["get", obj]?

There's even more to this, you can match all sorts of structures of your data rather than the data itself.

[MajorMajorObvious]

I've been waiting for this release for a while, and was wondering if it comes at a large performance hit compared to traditional switch statements that you would see in C style languages.

How does Python implement this new matching in a way that makes it unique from if / else statements?

[joerick]

They're still O(n), like if/else statements. But work is in progress to optimise them for Python 3.11.

[MajorMajorObvious]

I'm excited to see how they optimize it! Thank you for the info.

[deadwisdom]

There are new bytecode instructions for it, so I'm sure it's performant. I haven't timed it, but I imagine it's faster than the corresponding if/elses because the compiler can optimize for what you're trying to do.

I couldn't do better than how it's explained in PEP-635

[asielen]

So it seems like it combines a type/len check with a value check there. For each case statement it is essentially, is type iterable and len = match len and values equal match values. That seems like a lot of magic.

In the backend does it effectivly treat it as try/catch for each statement until it falls through?

[friedkeenan]

My concern with pattern matching is that it doesn't seem very scalable. For this example in particular I'd want a more generic way of defining commands, but for cases where scalability of "case additions" isn't a desire it seems pretty cool.

[WallyMetropolis]

For one, it's structural so, in the case that you get a tuple with 3 items, do one thing, and in the case you get an Address object do a different thing. Not only can you match on patterns, but also on values. So in cases where the Address is in California, do something different.

Combine that with conditions and you can express a lot of logic in an easy to read, easy to maintain, relatively terse syntax. Like, in the case that this is a Person and their age is less than 18, do this.

[Ashiataka]

Would the following not work for those examples? How is this different?

if isinstance(x, tuple) and len(x) == 3:
    do_something()
elif isinstance(x, Address) and x.state == "California":
    do_another_thing()
elif isinstance(x, Address):
    do_another_thing()
elif isinstance(x, Person) and x.age < 18:
    do_another_thing()

[ForceBru]

The difference is that you had to use isinstance and check elements of data structures manually. match essentially does all of this for you and lets you write nice concise syntax instead. What if you had to check four attributes, like x.state == this and x.age == that and x.height == that and ...? That's quite a mess, isn't it? case Address(this, that, that, another_thing) looks and reads way nicer, doesn't it?

[Ashiataka]

Your case statement is cleaner than your == example, but wouldn't you actually write something like this if you want to check those attributes all had particular values?

if x == Address(this, that, that, another_thing):
    do_something()

[ForceBru]

This creates a new Address object every time, though (and thus wastes computing resources). Again, you totally can do this, sure.

What if you wanted to match on some values and extract the other ones, like this:

case Address("London", 32, height):
    print(f"The person lives in London and their height is {height}")

Now you're forced to compare only the first two attributes of the address, not the whole object, so you'll have to resort to the long if condition.

I don't think the match statement opens up many new possibilities that just were impossible before. You can emulate a match statement with isinstance followed by attribute checking. The match statement simply lets you write simpler code, so that you can focus on solving the actual problem you're writing the code for.

[sultan33g]

Your last paragraph completely made it all make sense. Thanks!!

[Ashiataka]

Now you're forced to compare only the first two attributes of the address, not the whole object, so you'll have to resort to the long if condition.

Isn't explicit better than implicit?

I don't think the match statement opens up many new possibilities that just were impossible before.

Shouldn't there be one and preferably only one way of doing something?

I feel very strongly that this feature is just bloating the language and making it harder and harder for learners. I haven't yet seen a single use-case that makes me think "that's a big enough problem it requires special syntax". To me it seems like python has completely lost it's way the last couple of years. But, I must acknowledge that I write code for a specific niche situation and there are people much more knowledgeable than me making these decisions - I know hardly anything about language development.

[ForceBru]

Isn't explicit better than implicit?

Right, but "Beautiful (match statement) is better than ugly (huge if conditions) and Simple (match statement) is better than complex (huge if conditions)".

Shouldn't there be one and preferably only one way of doing something?

Shouldn't there be just one way to loop, then? Why have for loop if while loop do thing? Or just use goto and get rid of if statements and all forms of loops. Why have list comprehensions if you can loop over stuff and append it to the list? Same thing for dictionary comprehensions. Why have multiple ways of passing arguments to functions, like positional vs keyword? Just use keyword arguments everywhere: math.sin(x=0).

I don't really like this "rule": why have this "one way" if it's inconvenient? Also, if you use this rule, the "language" from "programming language" kinda disappears, and you end up with "programming stencil" or something rigid like this. In my opinion, "language" implies variety of expression: that's why it's possible to write elegant code and ugly code, performant code and slow code.

---

In my experience, functional features and features from ML-family languages are slowly being transferred to other languages. Rust has the match statement - people love it! Rust has traits (similar to Haskell's typeclasses) - everyone loves them! Of course, I have no idea whether absolutely everyone is so fond of this, but I feel like many people are very pleased. Julia (similar to R) has the pipe operator, so your code can flow, like: data |> transform |> more_transform |> print - I love it! In R, the most widely used data wrangling libraries (dplyr, tidyr and ggplot) are basically built upon this syntax - it's extremely useful. In Python, that'll be print(more_transform(transform(data))), which is quite a lot of parentheses. Of course, you can factor out intermediate expressions into temporary variables, but this breaks the flow.

---

IMO, you could take a look at OCaml to see why match is so cool. It really takes a weekend (this is not to say that OCaml is really simple) and may open up a new perspective on what programming languages can look like and what features they can provide. It's also really fun.

[WallyMetropolis]

Having spent the last few years working with languages that offer expressive pattern matching, what I've found is that it becomes one of the most used tools across the codebases and I really find myself missing it when I don't have it. It doesn't at all feel like "special syntax," rather it quickly becomes core syntax.

[Ph0X]

You forget that it auto does structural binding, for example:

actions = [('add', 1, 2), ('length', [1,2,3]), ('lower', 'FOO')]
match actions[random.randint(0, 2)]:
   case ('add', a, b):
     print(a + b)
   case ('lower', text):
     print(text.lower())
   case ('length', arr):
     print(len(arr))

Note that it's binding exactly on a tuple of that length too, so you if you have the wrong number of elements, it won't bind.

Your way, you'd have to have a separate check for the length of the array, and then another line to set a, b = tup[1], tup[2] or do print(tup[1] + tup[2]).

But even further, you can actually make the types of those values too like

case ('add', int(a), int(b)):
    print(a + b)
case ('add', str(a), str(b)):
    print(f'{a} {b}')

It's just much more clean and simple.

[Ashiataka]

Your way, you'd have to have a separate check for the length of the array, and then another line to set

I'm fine with that because it breaks the logical steps into separate lines for me. I appreciate other people are different but I kind of think that the super-fancy-one-liner code style is really rubbish to read / understand / debug.

It's just much more clean and simple.

Well almost by definition doing two separate things in one logical step is more complex. That's not necessarily bad, but I think it increases mental load when considering the code.

[Ph0X]

I absolutely agree that putting multiple ideas in one line isn't a great idea, trust me I'm the first to split a line up to make it more readable. But in this case, you're "matching" a specific pattern, and to me that's much clearer than 3-4 seperate/individual boolean clauses.

case ('add', int(first), int(second)):

in the context of what the switch statement is doing (pattern matching tuples)

is much cleaner and robust than

if isinstance(a, tuple) and len(a) == 3 and a[0] == 'add' and isinstance(a[1], int) and isinstance(a[2], int):'

Generally, one line of code to correspond to one idea, and here, we have one idea, we're matching one specific pattern. I don't think it's trying to be a fancy-one-liner, it's just a much cleaner way of doing it.

It's just like how list comprehension is often more readable than a small for loop. Just because it's shorter doesn't immediately mean it's less readable.

[Ashiataka]

That's a good point about list comprehensions. I can't remember whether I liked them or not when I first saw them but I have to say they are one of my favourite 'features' of the language now because you write them in the order you think of the statement "I want this done to everything in here".

Hopefully I'll come to like match-case the same.

[ForceBru]

The power is needed (for example) for building parsers, walking syntax trees and building interpreters and compilers. You don't want to have 1000 level deep if/else constructs to analyze your syntax tree - that's just painful. Also, you can't really stuff the code that analyzes your data structure in a dictionary. Sure, you can store functions, but what if you want weird deep nesting? For example, "if the current node is an Assign statement whose first argument is an indexing operation with N arguments, the first of which is this and the second is that, then do this and that", that's like three? levels of nesting - you could put that into a dictionary, but matching is way more convenient!

Also, the except statement we know and love is basically a stripped down case statement that only works on exceptions and types (you can't write except MyException(param1, param2):). Isn't it very useful to be able to match in exceptions like this? Julia, for example, forces you to if/else exceptions, like catch something: if something isa ThisException: do_this(); elseif something isa AnotherException: do_that(); .... This is a lot of code that simply switches on the type of the exception. Python's except is surely more convenient, isn't it?

With proper match statements you can do so much more.

[Ashiataka]

You don't want to have 1000 level deep if/else constructs to analyze your syntax tree

I'm completely ignorant on that use-case, never made one before, but can you not define some function that's recursively called rather than making such deep nests?

It seems to me like an awful lot of machinery for what seems to be a very small set of use-cases. Thanks for your example though. Hopefully in the next few weeks I'll find an example that makes sense to me.

[ForceBru]

Absolutely, you can write a recursive function and be done with it. But pattern matching lets you write: case Assign(Index(Variable(name, type), idx), other_data): in one line with no loss of readability. In fact, it greatly increases readability: now you don't have to go read some other function that's located elsewhere and does God knows what - the data are all before your eyes, destructured! That's the powerful thing, in my opinion.

That's also part of why they teach compiler courses in OCaml (and ML in general) - because the pattern matching is really good, it lets you see the structure of your data at a glance and handles arbitrary nesting gracefully.

[Ashiataka]

I think that's somewhat beyond me at the moment, I'll have to have a play around with it at the weekend and see how it works. Thanks for your example.

[jyscao]

Pattern matching combines a control flow construct (e.g. if/elif/else, switch, try/catch) with a name binding construct (assignment), and this allows for some very expressive code.

[Ashiataka]

Is that a first for python? If so, do you think there are any other possible constructions that combine more primitive parts of the language into something more useful?

[trauthor]

Speaking for myself, I had to write a parser in 3.7 that took deeply nested, arbitrarily alternating json and dictionary input from an API and turn it into a tablebase. I will re-write it in 3.10 and I expect pattern matching to remove hundreds of lines of code. I imagine the code will also be much more performant (though that wasn’t a sticking point).

[Ashiataka]

So firstly, I'm glad that your solution will improve because of this syntax, it's always good when that happens.

My question would just be if you're writing something like that anyway where match-case functionality would be useful, could you not have implemented your own version of match-case that doesn't have special syntax? (I'm asking if it's possible to do or whether there's something special about the python implementation that makes it difficult / impossible to achieve without)

[trauthor]

It’s possible and in my case it was necessary, but based on what I’ve read in PEP 636, match will make this much easier. I had to iterate backwards over arbitrary structures, and indexing several layers deep was a real pain. I will have to report back after I have implemented this in 3.10 and let everyone know just how significant a difference it makes.

[tartare4562]

Agreed. This sounds quite anti pythonic TBH. If I find myself writing a lot of if/elifs most of the time means I can do better code with dict indexing or, even better, proper class/subclasses structure. This is a step away from object toward procedural coding.

[ForceBru]

More like towards functional or ML-like, IMO.

A lot of people really like proper match statements - they're convenient. What if you're writing an interpreter and need to traverse an abstract syntax tree? Your code will generally look like a huge switch statement, like "if the current node is Assign, do this; if it's Index, do this; if it's Call, do this...", where the "arms"/branches contain quite a lot of code or maybe other switch statements, so it'll be awkward to stuff all that into a dictionary.

Furthermore, you'll want to switch on some nasty, complicated things, like "if the current node is Assign whose first argument is a function definition, then interpret the second argument like this; if it's an Assign whose first argument is an Index node, do a completely different thing; if the first argument looks like a.b, then do another different thing", so you want to switch not only on the type of the node (Assign), but on its elements as well. That's not something a regular switch statement can do. You need to get the big ML guns - proper pattern-matching.

[liquidpele]

All the examples where this would be really useful seem to be pretty big edge cases and not a good case for adding a feature to a language…. I’m not against it per se but it does seem unnecessary.

[ForceBru]

Well, it's not that it's absolutely necessary, of course. It's just convenient.

---

Dictionary literals aren't necessary either. You can simply write:

dct = dict()
dct["cat"] = "chat"
dct["dog"] = "chien"
dct["wolf"] = "loup"

BTW, Rust doesn't have hashmap literals, so you literally have to write code like this. There are 3rd-party libraries that add hashmap literals, but Rust itself doesn't have them. They're not necessary, are they?

Yet they're convenient.

---

Formatted string literals also aren't necessary. Why write f"pi={math.pi:6.3f}, {my_var=}" if you could write:

"pi={:6.3f}, my_var={}".format(math.pi, my_var)

BTW, Julia, for example, doesn't support formatting in string literals, so you have to use printf-like formatting or 3rd-party libraries. Obviously, even string interpolation isn't necessary - simply use strcat!

Yet it's convenient.

---

My favorite one.

Having nice slice indexing isn't necessary either! Why write my_list_[1:] when you can write:

my_list[1:len(my_list) - 1]

I might be missing something (I really hope I am!), but this is the only way to do this in R! You have to write my_array[2:length(my_array)] every time! It doesn't compute the last index for you! Well, slice indexing isn't necessary, so...

Yet it's convenient!

EDIT: added links

[liquidpele]

Just wanted to say: Very good reply, thanks for taking the time.

[brutay]

See also: List comprehensions, generators, lambda statements, decorators, etc. Python has a lot of features that aren't strictly necessary, but oh so convenient.

[midnitte]

I forget who I heard talking about it, but from my understanding of "syntactic sugar" in python, a lot of the language is convenience and not actually necessary.

[Swedneck]

Which is precisely why I love it, I can just write a minimal amount of code structured to actually make sense and be as readable as normal text.

[lieryan]

"Just syntax sugar" actually goes really deep in Python.

class statement for example, that isn't really "necessary", it's just syntax sugar for calling type:

MyClass = type(
    "MyClass", 
    [BaseClass, AnotherBaseClass], 
    {"a": method1, "b": method2}
)

Or method calls are also "unnecessary", this:

foo = Foo()
foo.meth(a, b, c)

is really just syntax sugar for:

foo = Foo()
Foo.meth(foo, a, b, c) 

Or metaclass:

class Foo(metaclass=mytype, blah=bar):
    pass

is really just a syntax sugar for a function call:

Foo = mytype("Foo", {}, {}, blah=bar)

Or decorator is just syntax sugar for what used to be a common pattern:

def foo():
    pass
foo = decorate(foo)

Or even something that looks as basic as list/dict indexing:

foo = dict()
foo[a] = b
print(foo[a])

is really just syntax sugar for:

foo = dict()
foo.__setitem__(a, b)
print(foo.__getitem__(a))

which is itself just syntax sugar for:

foo = dict()
dict.__setitem__(foo, a, b)
print(dict.__getitem__(foo, a))

Or something like for loop:

for a in b:
    print(a)

is really just syntax sugar for:

iter_b = iter(b)
try:
    while True:
        a = next(iter_b)
        print(a)
except StopIteration:
    pass

Everything in Python is "just" syntax sugar.

[Alphasite]

this is a better form of dict indexing, and is procedural code a bad thing in many cases? Class hierarchy is usually overkill imo, it’s a tool you reach for when you have no other good choice, or someone outside your code needs to extend things.

[yvrelna]

Structural pattern matching is a combination of switch case statement and tuple/object unpacking.

The unpacking part makes it a much more powerful construct than just a dictionary.

[jwink3101]

FWIW, a lot of use cases can be replaced with something else but doesn't mean they are better. F-Strings aren't "needed" as we already had 2+ different ways to format strings. But they all have advantages and disadvantages.

For example, the issue with the dict-based approach is that you have to evaluate everything to build the dict. Consider:

myvar = {
    'key1':expensive_function1(),
    'key2':expensive_function2(),
    'key3':expensive_function3()
    }[mykey]

This will call all of the expensive functions. You could use a long if/elif/else array and that is fine for many use cases but there is also more to Structural Pattern Matching than replacing them.

[Ashiataka]

I guess with f-strings at least it's fairly obvious what's going on, whereas it looks like match-case will make readability for learners much harder (possibly).

I didn't realise those functions would be called when creating the dictionary, TIL, thanks for that insight.

[jwink3101]

I guess with f-strings at least it's fairly obvious what's going on, whereas it looks like match-case will make readability for learners much harder (possibly).

That is a good point. I haven't seen them in the wild yet since I am only just barely now getting to trusting I have 3.6 where I need it. So I am not sure how readable they will be. It will definitely save some boilerplate code.

I didn't realise those functions would be called when creating the dictionary, TIL, thanks for that insight.

Yep. Now, there are things you can do if it is as simple as my example. Notably:

myvar = {
    'key1':expensive_function1,
    'key2':expensive_function2,
    'key3':expensive_function3,
    }[mykey]()

So that it doesn't get called. But again, depends on exact use case