Hacker News Reader

Comment by pansa2 | Hacker News Reader

The real crime is the design of Python's pattern matching in the first place:

    match status:
        case 404:
            return "Not found"

    not_found = 404
    match status:
        case not_found:
            return "Not found"

Everywhere else in the language, you can give a constant a name without changing the code's behaviour. But in this case, the two snippets are very different: the first checks for equality (`status == 404`) and the second performs an assignment (`not_found = status`).

https://x.com/brandon_rhodes/status/1360226108399099909

View on HN

That's destructuring, a feature not a bug. Same as it works in any functional language - and tremendously useful once you get the hang of it

At least functional languages tend to have block scope, so the latter snippet introduces a new variable that shadows `not_found` instead of mutating it.

Destructuring is a feature. Making it easy to confuse value capture and value reference was an error. Add single-namespace locals and you have a calamity.

Destructuring yes but you can still argue it's poorly designed. Particularly unintuitive because matching on a nested name e.g. module.CONSTANT works for matching and doesn't destructure. It's just the use of an unnested name which does destructuring.

What Python needs is what Elixir has. A "pin" operator that forces the variable to be used as its value for matching, rather than destructuring.

No, at least in Erlang a variable is assigned once, you can then match against that variable as it can't be reassigned:

    NotFound = 404,
    case Status of
        NotFound -> "Not Found";
        _ -> "Other Status"
    end.

That snippet will return "Other Status" for Status = 400. The Python equivalent of that snippet is a SyntaxError as the first case is a catch all and the rest is unreachable.

It wouldn't be a problem is Python had block level variable scope. Having that destructuring be limited to the 'case' would be fine, but obliterating the variable outside of the match is very unexpected.

And there was a much better proposal that got rejected in favor of what we got: https://peps.python.org/pep-0642/

The very first example there shows a match/case block where almost every single case just runs "pass" and yet every single one has a side effect. It's very difficult to read at first, difficult to understand if you're new to the syntax, and is built entirely around side effects. This might be one of the worst PEPs I've ever seen just based on that example alone.

Fun fact: you can do the same thing with the current match/case, except that you have to put your logic in the body of the case so that it's obvious what's happening.

because it's not a `switch` it's a `match` ie pattern matching...

Doesn't matter what it is, it shouldn't break fundamental rules of the language.

Ruby's `case`/`in` has the same problem.

> it shouldn't break fundamental rules of the language

it doesn't? you simply don't understand what a match statement is.

https://doc.rust-lang.org/book/ch19-03-pattern-syntax.html

    let num = Some(4);

    match num {
        Some(x) if x % 2 == 0 => println!("The number {x} is even"),
        Some(x) => println!("The number {x} is odd"),
        None => (),
    }

notice that x is bound to 4.

> you simply don't understand what a match statement is

It's "a DSL contrived to look like Python, and to be used inside of Python, but with very different semantics":

https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...

you linked to a random detractors rant. i don't see what that has to do with whether a match statement binds a match?

Which x? There are two in your code, one for each time you introduce a pattern Some(x) and each x has scope which of course ends when that pattern is done with

Notice that the Python doesn't work this way, we didn't make a new variable but instead changed the existing one.

Also, the intent in the Python was a constant, in Rust we'd give this constant an uppercase name by convention, but regardless it's a constant and so of course matching against a constant does what you expect, it can't re-bind a constant, 404 is a constant and so is `const NOT_FOUND: u16 = 404;`

> Which x? There are two in your code, one for each time you introduce a pattern Some(x) and each x has scope which of course ends when that pattern is done with

if each x's scope ends at the end of each case doesn't that mean there's only one x?

> we didn't make a new variable but instead changed the existing one.

so because python doesn't have scopes except for function scopes it shouldn't ever have any new features that intersect with scope?

Also this is pretty much in line for the rest of Python leaving variables around.

    for x in [1]:
      pass
    print(x) # => 1

The match statement presented is equivalent to an assignment, you do have to know that, but then it's just regular Python.

Being in line with the bad original design decision is another bad design decision, python developers should have a courage to admit these instances to benefit from better decisions in new peps. They didn't do it with pattern matching and now the language has another inferior implementation of a feature that, if implemented correctly, should have had clear block scopes, defined as expressions (as opposed to statements), and disallowed type-diverging branches. Java has designed it right, by the way, despite having a differently behaving switch statement in the language already.

> Being in line with the bad original design decision is another bad design decision

I disagree. Consistently going with the "bad" choice (in this case, leaking the variable to the outer scope) is better inconsistently swinging between 2 ways of doing things. Least astonishment!

"We've made this mistake before so for consistency we need to repeat it" is such a bad idea. Ideally you want a way to go back and fix things you got wrong, but, even if you can't do that (which is itself a defect and you should figure out how you can improve) you should improve as you move forward.

C++ has struggled with this, so that paper authors sometimes plead with the committee not to make their proposal needlessly worse in the name of "consistency" with existing bad features. This famously failed for std::span, which thus managed to be not only a real world footgun in a language which already has plenty of footguns but also a PR footgun - because for "consistency" the committee removed the safety from the safety feature and I believe in C++ 26 they will repair this so it's just pointless rather than actively worse...

> "We've made this mistake before so for consistency we need to repeat it" is such a bad idea.

no it's not. you literally have no other choice. you cannot add scopes after the fact - it is a breaking change. you cannot have some parts of the language have scopes and others not - it's so much worse for the user. think about human languages and which ones get quoted as being the hardest to learn (those with many exceptions). you're just wrong.

Or stated another way, adding block scoping necessitates Python 4. You could be cheeky and make it work in a backwards compatible way by adding new opt-in syntax but it wouldn't fix match nor be terribly ergonomic having to declare it all the time.

Reply on news.ycombinator.com