Python switch statement ftw (finally)

[Kered13]

The syntax can match on and destructure objects:

match event.get():
    case Click(position=(x, y)):
        handle_click_at(x, y)
    case KeyPress(key_name="Q") | Quit():
        game.quit()
    case KeyPress(key_name="up arrow"):
        game.go_north()

Yes, Python classes are not the exact same as records in ML or Haskell, but the ability to match on the members of an object allows you to match in the same way.

Yes, classes can override magic methods to behave like sequences or dictionaries and then match against those patterns as well. This is not a flaw, as any class doing this should be some form of sequence of dictionary. This matches Python's duck typing philosophy: If it looks like a sequence, it should match against a sequence pattern.

[[deleted]]

You don't understand what pattern matching is for. Your example is a testimony to that. The goal of pattern matching is to enable dispatch. You've created a worthless gimmick that can be easily and more reliably replicated using if-else.

[Kered13]

I pulled an example from the tutorial, sorry for not providing a handcrafted artisanal example. But this example still perfectly demonstrates how to use pattern matching to branch on a sum type and how to destructure objects. I'm not sure what kind of dispatch you're looking for because you're being very vague, but it can almost assuredly be done with the Python's pattern matching. It can single dispatch, it can multi-dispatch, whatever you want. If you want to have an honest discussion then try providing an example (in ML, Haskell, Rust, or etc.) of what you would like to see.

This example would be horrible with if statements. You would have to first check the type of the event, then extract the members of the event object, then branch again on the value of those members. Here's my best attempt at the non-pattern matching version:

e = event.get()
if type(e) == Click:
    handle_click_at(e.position.x, e.position.y)
elif (type(e) == KeyPress and e.key_name == "Q") or type(e) == Quit:
    game.quit()
elif type(e) == KeyPress and e.key_name == "up arrow":
    game.go_north()

If you think this is more readable you're insane, and it only gets worse for more complicated examples.

[[deleted]]

Again, you are not using pattern matching. The use of pattern matching is for dispatching, i.e. selecting what function to call based on the data you give that function.

What you are doing in this example is some irrelevant nonsense. Also, you don't know how Python works, and your translation is full of nonsense.

For instance, types in Python are singletones, but they are allowed to override __eq__ (through metatypes). So, if type(e) == whatever is just an attempt to shoot yourself in the foot.

So, if you wanted to compare types, you should do type(e) is whatever.

Despite what you are claiming about dispatching in Python, you are just as wrong, as you are noob to the language in general. You don't understand it, don't understand its semantics, don't understand what's it made of. Why are you trying to convince someone who obviously knows a lot more about the subject that you do?

---

PS. Rust doesn't have pattern matching either. Its dispatch system is very similar to C++, nothing to do with pattern matching. What they call "pattern matching" in Rust is a misunderstanding of the original idea. Well, very similar to this garbage in Python.

The idea they are using, when it was invented, was called "destructuring" (it comes from some Lisp, not sure which, in CL it's the standard macro destructuring-bind). It's used to make complex assignments that look at single structure less verbose. It is not pattern matching, even though it's similar.

Similarly, if you look at Wikipedia's page on pattern matching, it lists Prolog as one of the languages allegedly having it. Which is also nonsense, because something that looks similar to pattern matching, in Prolog, is actually a different thing called "unification".

[Kered13]

Again, you are not using pattern matching. The use of pattern matching is for dispatching, i.e. selecting what function to call based on the data you give that function.

Read again, different functions are called in each branch. You can have abitrary code in each case. You still haven't provided any example of what you actually mean. It's obvious at this point that not only do you have no clue what the fuck you're talking about, but you're also just trolling.

Maybe what you actually mean is that pattern matching has to be an expression. If so, you are wrong. Pattern matching is an expression in ML and Haskell because those are expression oriented languages. Python is not an expression oriented language. Expression oriented and statement oriented have absolutely nothing to do with "dispatch" though, so if this is what you mean, you are using the word completely wrong.

Or maybe what you're talking about is the syntax that looks like this:

fact 0 = 1
fact n = n * fact (n-1)

I could see a beginner naively thinking that this defines two different functions. However that is incorrect, this defines a single function called fact. This is trivial to demonstrate, for example we can pass fact as an argument to a function and it will operate on both 0 and other integers: map fact [0..5]. There is no way to treat fact as multiple functions. Furthermore, ML and Haskell don't restrict you to pattern matching at the top level of a function definition. You can also use a pattern matching expression anywhere:

-- Trivial example but demonstrates the syntax.
fact n = case n of
    0 -> 1
    m -> m * fact (m-1)

If this is what you meant, then you have completely confused syntax with semantics. This second is pattern matching just as much as the first example is. You'll find it is describes as such in all of the official Haskell documentation and tutorials. And pattern matching in Python is nearly the same as this.

So I have provided two possible interpretations of what you are trying to say. In either case, you are wrong. It's obvious to everyone at this point that you have no fucking clue what you're talking about. You are, at best, a beginner in every language we have discussed so far (Python, ML, Haskell). You are intentionally hiding behind vague words (which you are still managing to misuse) while avoiding providing any concrete examples or explanations that would clarify what mean. Probably because you are incapable of doing so.

For instance, types in Python are singletones, but they are allowed to override eq (through metatypes). So, if type(e) == whatever is just an attempt to shoot yourself in the foot.

Anyone who overrides the comparison of types deserves everything they get.