1. Semantic operator overloading in generic contexts is very different from this use case. It's surrounded by a clear context. 2. Python programmer intuition varies across python programmers, and I would find it hella unintuitive if I had to explicitly capture every variable. I just want to write down what the thing looks like and have the interpreter figure out the correct bindings. Extra binding syntax will get in the way rather than be helpful. Python Dev <python-dev@python.org> wrote: “+10. See https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262 for concrete evidence where another semantically inconsistent operator overloading caused trouble and what Stroustroup has to say on the matter.
On 31.07.2020 13:42, Larry Hastings wrote: “ On 7/31/20 12:36 AM, Tobias Kohn wrote:“And since pattern matching is really a new feature to be introduced to Python, a feature that can be seen in different lights, there is no 'Python-Programmer intuition' that would apply in this case. ” It's not fair to say "intuition doesn't apply because it's new syntax". There are plenty of examples of intuition serving a Python programmer well when encountering new syntax. A Python programmer's intuition is informed by existing syntax and conventions in the language. When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed. Take for example list comprehensions. Python 1 programmers hadn't seen “a = [x for x in y] ” But they knew what square brackets meant in that context, it meant "creates a new list". And they knew what "for x in y" meant, that meant iteration. Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and set and dict comprehensions they'd surely intuit what those did immediately. The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly different semantics. For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual semantics and behavior is very different. Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or undotted-identifiers when defining a key. Add the "capture pattern" to both of these, and a Python programmer's intuition about what this syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time. Cheers, /arry _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan”” [attachment.txt]
_______________________________________________ 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/4L7LXGVYTMHPF5I54Z2DVSIKSL75ES6H/ Code of Conduct: http://python.org/psf/codeofconduct/
