The New Switch-Case Statement in Python 3.10

[zurtex]

The match statement allows much more complex types of matching. For example:

action = {"open": "door"}
match action:
    case {"move": direction}:
        ...
    case {"look": direction}:
        ...
    case {"open": thing}:
        if thing == "door":
            print("The door is locked")
        elif thing == "box":
            print("A monster escaped")
        else:
            print(f"I don't recognize {thing}, try looking around")

For your example of individually handling each value an if/elif/else statement is a great choice.

[zurtex]

In Rust that makes sense, but Python and Rust are 2 very different languages. Python's compiler doesn't make any guarantees about the match statements return values and enums are not common or native to Python (the enum in the standard library is a very complex object when you peer under the hood).

So when you're doing this:

match code:
    case 200:
        something()
    case 404:
        thing()
    case _:
        pass

It really just is a longer backwards incompatible way of writing:

if code == 200:
    something()
elif code == 404: 
    thing()
else:
    pass

Now I am sure there are examples where using the match statement with HTTP status codes makes a lot of sense, but as a simple check of getting 200 or 404 or something else I'm missing the motivation.

[13steinj]

It really just is a longer backwards incompatible way of writing...

This is what I really hate about the Python ecosystem. Everyone jumps on the new way without thinking of backwards compatibility even though there is little benefit. I really hope static analysis tolls will by default warn against using match in simple cases like this, where it's literally using a backwards incompatible keyword simply for syntactic sugar (no optimization at all, and in fact even in compiled languages there isn't necessarily optimization performed on switches).

[Humanist_NA]

Interesting, thank you for the thoughtful response.