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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/VJ7XJE4JEPK2FGKGB7AG4IHFYKOXFVU5/
Code of Conduct: http://python.org/psf/codeofconduct/
