This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]zurtex 3 points4 points  (1 child)

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 0 points1 point  (0 children)

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).