Adding this feature would be a giant quality of life improvement for me and I really hope it succeeds. So I have been trying to keep up on the debate in this and related thread.

While I do want this feature, I agree with a lot of the issues people are raising.

First I agree that _ should not be the wildcard symbol. Or rather the hobgoblins in my mind think that if _ is to be the wildcard symbol it would be more consistent with assignment if it was bound to the last value it was matched with (as should other repeated identifiers) e.g.,

match pt:
   case (x, _, _):
       assert _ == pt[2]

I understand the authors rationalize the decision based on conventions with the gettext module. I find these arguments very unconvincing. It's like saying the identifier np should be forbidden from appearing in cases because it's frequently used as the name of numpy. If there is to be a wildcard symbol (that does not bind and is repeatable) it should not be a valid identifier.

Second, the distinction between a capture and constant value pattern should be more explicit. I don't have any great insight into the color of the shed beyond the numerous suggestions already made (name=, ?name, etc...), but it seems quite unintuitive to me that I can't capture into a namespace nor match a constant without a namespace. It is also unclear to me why it would be so terrible to add a new token or abuse an existing one.

> Honestly, it doesn't help the case for `?` that it's been proposed as a mark for both capture patterns and value patterns (by different people, obviously :-).

I agree that most of the proposed sheds don't necessarily make it intuitively clear what is a capture variable vs what is a constant. However they do give the programmer the ability to choose.

For example if I want to modify the motivating example from the PEP slightly to copy attributes from one point to another I can't express it concisely:

def update_point_3d(p: Point3d, pt):
    match pt:
        case (x, y):
            p.x, p.y = x, y
        case Point2d(x, y):
            p.x, p.y = x, y
        ...

(Okay I could have just called the original make_point_3d and unpacked the results but it would require the creation of an unnecessary temporary.)

However if the capture was explicit and any valid target could be used as a capture variable then I could express this cleanly:

def update_point_3d(p: Point3d, pt):
    match pt:
        case (p.x=, p.y=):
            pass
        case Point2d(p.x=, p.y=):
            pass
        ...

- Caleb Donovick