On Thu, Jul 16, 2020 at 9:21 AM Federico Salerno <salernof11@gmail.com> wrote:
[...] 
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 _:
         ...

During our internal discussions (before we published the first draft) I briefly proposed a similar idea. But it was quickly pointed out by my co-authors that this doesn't fly, because when the parser sees `case other_3d_point:` it doesn't know whether you meant this as a capture pattern (binding the variable `other_3d_point`) or as a pattern object. Also with your proposal the compiler would not be able to tell that x, y and z are local variables, because they are only mentioned inside string literals.

Another way to look at it: if you have some common assignment target, say:
```
x, y, z = point1
x, y, z = point2
x, y, z = point3
```
you can't define an object that serves as a shortcut for the `x, y, z` assignment target -- this (obviously!) does not work:
```
xyz = AssignmentTarget("x, y, z")
xyz = point1
xyz = point2
xyz = point3
```
(You could construct similarly absurd examples for function signatures.)

Patterns are more like assignment targets or function signatures than like expressions, so we shouldn't be surprised that we can't define objects to serve as shortcuts here. It could probably be done with a suitable macro preprocessing feature, but that's a much larger discussion (that I'm definitely not going to tackle).

--
--Guido van Rossum (python.org/~guido)