Matching *should* look like instantiation ...
case Point(2, 4)
*should* mean "Does it match the object that Point(2, 4) would create?".
case Point(2, y=4)
is less crucial, because they *could* rewrite the call -- but why should they
have to? Changing from constants, and
case Point(x=a, y=b)
suddenly means x is the already externally bound name and *a* is being assigned
to, so it doesn't need to have been defined previously? What advantage can
there be in re-using syntax to mean something opposite to what it normally does?
Others have objected to both
case Point(x as a)
and
case Point(a:=x) # I dislike it, but it isn't as bad as the raw =
but I am missing the problem, other than the confusion binding always brings.
To me, they do both seem to say "It matches the object that would be created by
Point(x) for *some* x, and an example/witness x that works is now stored in a.
If there is no way to resolve this, I would honestly prefer to require nested
matching, vs using call signatures in a way opposite to their normal usage.
-jJ
_______________________________________________
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/ETWGXN3QMKFK6E2LNSAVMZATT625QJ74/
Code of Conduct: http://python.org/psf/codeofconduct/
