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 -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ETWGXN3QMKFK6E2LNSAVMZATT625QJ74/ Code of Conduct: http://python.org/psf/codeofconduct/