Recent discussion on the store vs. load syntax issues of PEP 622 prompted a (yet unripe) idea that could hopefully spur some progress. What if cases required some sort of MatchCase (name pending) object which could be preconstructed by the user if needed, but also inferred on the fly if absent? I think an example would clarify what I mean. Consider the following block (with & to mark "load" just for demonstration purposes): match some_point:     case Point(x, y, _) if x > y:         print(f"Tridimensional point with x > y")     case Point(_, _, _):         print("Some other 3D point.")     case Point(_, &my_y) as pt:         print(f"{pt} has y=={my_y}.")     case Point(10, _):         print("Some bidimensional point with x==10.")     case Point(_, y):         print(f"Bidimensional point with {y=}.")     case _:         print("Something else.") This is admittedly simple enough that it wouldn't require what I'm about to show, but it does require marking my_y in some way to prevent it from being interpreted as a "store" identifier, or to namespace it for the same reason. Now consider the following refactor: 3d_point = MatchCase("Point(x, y, z)") other_3d_point = MatchCase("Point(_, _, _)") point_with_my_y = MatchCase("Point(_, {})", my_y)  # syntax with {} is debatable. other_2d_point = MatchCase("Point(_, y)") match some_point:     case 3d_point if 3d_point[0] > 3d_point[1]:         # 3d_point exposes x, y, and zwith the names given         #  in the declaration, as well as numerically,         #  through __getitem__ or perhaps also through attributes         #  like .args and .kwargs.         ...     case other_3d_point:         # other_3d_point[0] through [2] are available, while         #  other_3d_point["_"] == other_3d_point[2] because it's the last         #  one that was given. Presumably the programmer wouldn't care about it.         ...     case point_with_my_y as pt:         # pt still exposes positional arguments like pt[0], pt[1] or pt.args         #  as well as pt["_"] (== pt[0] in this case), but pt[1] has no         #  equivalent in pt.kwargs because no name was given.         ...     case Point(10, _):         # Python would construct its own MatchCase here and behave as expected.         ...     case other_2d_point:         print(f"Bidimensional point with y={other_2d_point['y']}.")     case _:         ... Every case above could be constructed in the same way as in the example without MatchCase, except for point_with_my_y, which contains a lookup: every identifier inside the match is interpreted as "store" unless it's namespaced; the others are included for demonstration purposes. As seen in case Point(10, _), patterns that contain no "load" identifiers can be written without using MatchCase instances. In effect, its usage would be a sort of "plug-in" for when complex or verbose functionality is needed, allowing to load identifiers or encode patterns for readability and/or reuse through the match block. The value of the identifiers to load would be read at MatchCase instantiation and internally converted to a constant value. Guard clauses could optionally be included in the MatchCase instantiation. If both it and the case: provide guards, they are anded together. If deemed appropriate, a special meaning could be given to MatchCase() (no arguments, or with "" or even any falsy value as argument) to represent the default case to appease those who don't like _. Note that the above examples assume at least _ (and possibly any identifier) can be repeated. My proposed MatchCase idea is compatible with the possibility of disallowing repeated identifiers, while still allowing them in MatchCase()'s first argument with the behaviour seen in the other_3d_point case. The constructor MatchCase could be either provided as a builtin or in a stdlib module that must be imported. I think the latter would be more reasonable. Any specific syntax or name presented above (MatchCase, the {}s in its first argument, the names of the MatchCase.args and MatchCase.kwargs attributes) is debatable. I hope I haven't missed any important point that would make the above demonstration invalid. Any thoughts?