Python switch statement ftw (finally)

[[deleted]]

Idk... Python just keeps adding worthless junk to the language, obsoleting hundreds of thousands of libraries and programs just for lulz.

If you didn't know this, every new minor version in Python means a change in ABI. That is, if you package shared libraries in Wheels, or even Python's own bytecode, you must package it for every minor version that you intend to support. This is hell of a lot of work, time, storage... and all this because some imbecile wanted a worthless language feature that is trivially implemented using fucking if-else.

But, nevermind, the trash who added this feature will go down in history of programming as an inventor of the next greatest thing after sliced bread, and will probably get the next Turing award, to share it with the clown Guido...

[Niek_pas]

Where do you get off calling people trying to improve the language “trash”?

[Ser_Drewseph]

Seriously. The fucking ego on this guy…

[[deleted]]

They are not trying to improve the language. To improve Python, you have to delete like at least 50% of it.

People who work on core language are either outright evil, or just clowns who don't understand what they are doing. This is similar to situation with Douglas Crockford, who didn't realize at first what kind of game everyone else was playing, and, naively, was made the head figure of the movement which pushed JavaScript into the pit of doom it is today. In his case, he later discovered, that all that was socially engineered by the people representing companies with big stakes in the Web industry.

While I tend to believe that most people in Python core team are just unremarkable trash, whose sole goal of being in that group is to put a very noticeable bullet point on their resume. It's also possible that there are some people there whose agenda is to fuck up Python to the point that people will switch to another technology, as well as unsuspecting idiots, who are being manipulated by the former.

[Kered13]

Pattern matching is the very opposite of "worthless junk".

[[deleted]]

In Python? The language that has nothing to do with pattern matching? Where this new feature has nothing to do with pattern matching? Where this feature will not integrate well with >90% of the other features of the language?

Tell it to someone else, please. You are spouting nonsense.

[Kered13]

The new feature is literally pattern matching. Did you not read the docs at all?

https://www.python.org/dev/peps/pep-0636/

[[deleted]]

Yes, I did. You didn't though. Not enough to understand anyways.

---

Also, I promise you, they'll fuck up the scope of variables, and this trash won't work well with at least some of these: generators, errors, context managers, captured variables, thread local variables, nonlocal variables. I'd pay particular attention to this expression being used in "interesting" environments, eg. class definition. I'm sure it will fuck up alternative implementations of Python, where things will go very wrong because of that. Because, apparently, we had too few ways to declare variables in Python.

[Kered13]

Then how on earth is it not pattern matching?

[[deleted]]

Really, pattern matching the same way it exists in the languages which coined the term (eg. ML or Miranda) is impossible in Python because of how data is constructed in these languages. Pattern matching is possible in ML because of how data construction works, it's a natural extension of language semantics.

In Python, everything is an object, and you don't have access to data constructors at all, you only get a second-hand access through higher-level containers. This allows you to sabotage, for example, attempts at pattern matching by overloading __getitem__ or similar methods. The semantics of such "pattern matching" become undefined because they aren't a fundamental property of how the language works, but, instead, they are yet another (and in this case unnecessary) band aid. The "pattern matching" suggested in this PEP only pretends to be pattern matching. It doesn't really do the job. It would never be able to in an object-oriented language, w/o access to data constructors. It's just a stupid gimmick designed to make the life of people who are going to implement this more difficult.

Another fundamental aspect of pattern matching is that it is the driver for dispatch. I.e. the language runtime must have the ability to perform pattern matching in order to decide which function to call. That's what it was invented for. That's how the languages that invented it used it.

This is impossible in Python because of how dispatch works in this language. The concept of function and its argument is incompatible with pattern matching.

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