Comment by r-zip | Hacker News Reader

Comment by r-zip | Hacker News Reader

I think pattern matching is super powerful, reduces boilerplate, and is not that hard to understand if implemented well.

I also think those who complain about the decline of Python's beginner-friendliness need to take a step back and understand that this is one of the most popular languages in use today. Reducing code maintenance issues (by eliminating boilerplate) will save many programmers time, and when you multiply average savings per person by the total number of programmers using Python day-to-day, I think adding certain features is a net positive. The time taken to learn this feature is small, and it's a one-time investment for each programmer. I don't think this is even a difficult feature to learn at a coarse level, since parameter unpacking/binding is already part of Python (think `for k, (x, y) in enumerate(list(zip(xs, ys)))...`.

All that said, I'm a bit concerned about how this is implemented. Many have raised the issues of unintuitive binding of non-dotted names, lack of local scope, and overloading of the `|` operator. I can't understand why these problems were not addressed during the PEP process. Does anyone have any insight?

lack of local scope, specifically, seems tied to Python's general lack of scoping beyond function contexts. Which is definitely a footgun for people coming from languages with full block scoping (which I strongly prefer), but at the same time I can see an argument for it making a lot of sense to most beginners to programming, who "look upward", see a name, and wonder why they don't have access to that name.

I agree about the unintuitive binding of names, though presumably the rationale is simply that any other approach would have introduced a significant amount of boilerplate. The only syntax I can think of would require a "bare as", e.g.:

  FOUR_HUNDRED = 400
  NOT_FOUND = 404
  match code_and_val:
      case (FOUR_HUNDRED, as x):
          print(x)  # FOUR_HUNDRED is not bound at all, but simply matched
      case (NOT_FOUND as x, as y):
          print(x, y)  # prints 404, code_and_val[1]

which looks quite weird to a Python programmer, though in this case I suppose you could argue that explicit is better than implicit.

not sure why the `|` overloading is a big deal here? there's no other significantly useful meaning for it in this context. Can you be more specific?

Realistically, any practical argument for Python's lack of block scope is probably just sour grapes. The real reason, I'm guessing, is that it started out as a hobby project 30+ years ago, and that block scope is not something GvR personally felt was worth the effort to implement at the time.

Followed by three decades of not wanting to do that particular breaking change, because doing so would be far more painful than anything that happened in Python 3.0.

> ...because doing so would be far more painful than anything that happened in Python 3.0

Is this really true? I don't think lack of block scope is ever used for anything but causing bugs.

Could do it the same way JS did it, with const and let keywords. Breaks nothing.

I only vaguely looked into all the conversation that went into this feature. But my sense is that, in a nutshell, folks figured out, after a lot of really impressive work on ironing out all the details, that there just isn't any to integrate this feature into the existing language without introducing footguns. The decision then came down to, "Do we drop the feature, or push it through anyway, warts and all?" And some combination of strong desire for pattern matching at any cost and anxiety over sunk costs means that the second option won.

IOW, design by committee doing what design by committee does best.

> overloading of the `|` operator

There’s a short discussion of this here: https://github.com/gvanrossum/patma/issues/146

Reply on news.ycombinator.com