IMO the match statement has some very unintuitive behaviour:

    match status:
        case 404:
            return "Not found"

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

The first checks for equality (`status == 404`) and the second performs an assignment (`not_found = status`).

`not_found` behaving differently from the literal `404` breaks an important principle: “if you see an undocumented constant, you can always name it without changing the code’s meaning” [0].

[0] https://twitter.com/brandon_rhodes/status/136022610839909990...

I see. Is it fair to say your issue with the feature is less about not wanting the feature and more about the implementation details?

Actually, I don’t really want the feature. It’s complicated and it doesn’t really fit with the rest of the language (it breaks fundamental rules, as above, and has scoping issues).

Worst of all, though, it’s really just another way to write if-elif-else chains that call `isinstance` - a pattern which Python traditionally discouraged in favour of duck-typing.

Aw dang you spoiled it :-) I was hoping my example would be more fun to work through haha.

What's the output of this program?

  class C(object):
      A = 1
  
  B = 2
  
  x = 3
  y = 10
  print(x - B)
  match y:
      case C.A:
          print('A')
      case B:
          print(y - B)

Do you not like the idea of pattern matching as a feature or do you not like the implementation details? This kind of seems like another clumsy scoping problem, no?

I would love a good pattern matching feature, but this is not it. And this is a seriously broken design at a fundamental level, not an "implementation detail". I actually have no clue how it's implemented and couldn't care less honestly. I just know it's incredibly dangerous for the user to actually use, and incredibly unintuitive on its face. It's as front-and-center as a design decision could possibly be, I think.

And no, this is not really a scoping issue. Match is literally writing to a variable in one pattern but not the other. A conditional write is just a plain inconsistency.

The sad part is both of these features are stumbling over the fact that Python doesn't have variable declarations/initialization. If they'd only introduced a different syntax for initializations, both of these could have been much clearer.

> I actually have no clue how it's implemented and couldn't care less honestly.

I guess I'm not sure where "design" ends and "implementation" begins? To me, how to handle matching on variables that already exists is both, because "pattern matching and destructuring" are the features and how that must work in the context of the actual language is "implementation". It being written in a design doc and having real world consequences in the resulting code doesn't make it not part of the implementation.

Instead of quibbling over terms, I was much more interested in whether you like the idea of pattern matching.

I think not liking the final form a feature takes in the language is fundamentally different from wholesale disliking the direction the language design is going.

Design is the thing the client sees, implementation is the stuff they don't see. In this case the user is the one using match expressions. And they're seeing variables mutate inconsistently. It's practically impossible for a user not to see this, even if they wanted to. Calling that an implementation detail is like calling your car's steering wheel an implementation detail.

But I mean, you can call it that if you prefer. It's just as terrible and inexcusable regardless of its name. And yes, as I mentioned, I would have loved to have a good pattern matching system, but so far the "direction" they're going is actively damaging the language by introducing more pitfalls instead of fixing the existing ones (scopes, declarations, etc.). Just because pattern matching in the abstract could be a feature, that doesn't mean they're going in a good direction by implementing it in a broken way.

I guess like they say, the road to hell is paved with good intentions.

> Design is the thing the client sees, implementation is the stuff they don't see.

By this definition, bugs and other unintended consequences that the user encounters are "Design".

> Calling that an implementation detail is like calling your car's steering wheel an implementation detail.

Yes, if there weren't so many important decisions behind the outcome of a car being steered with a steering wheel, it could be a steering handle, or a steering joystick, or just about anything else that allows you to orient the front wheels of the car. The same is true of the pedals on the floor. Those could be implemented as controls on the steering wheel instead. Whether it's an implementation detail depends on the specificity of the feature in question. When I asked you about an "implementation detail", it was scoped to "the feature is pattern matching" (can I steer the car?) and you scoped it to "the feature is pattern matching without overwriting variables conditionally in surprising ways" (can I steer the car with failure modes that aren't fatal?).

> Instead of quibbling over terms

and then all that?

Yes, I am definitely now quibbling over terms. I'm not sure what an appropriate response would have been? Just silence? You responded rather uncharitably and I didn't like it. I felt the need to defend my position.

Not silence, just continuing whatever your underlying point was if your goal wasn't to quibble over semantics. Now I have no idea what you're referring to, but this is clearly getting personal, so let's just leave this here. I think at this point we're both clear on the concrete problems with these features and what our positions are.