Hello, On Tue, 15 Dec 2020 23:28:53 +1100 Steven D'Aprano <st...@pearwood.info> wrote:
> On Tue, Dec 15, 2020 at 01:16:21PM +0300, Paul Sokolovsky wrote: > > > You're now just a step away from the "right answer". Will you make > > it? I did. > > Sorry Paul, but you didn't. > > You fooled yourself by comparing chalk and cheese, and imagining that > because you can eat cheese (change the order of operation by using > parens, which is a semantic difference), you can also eat chalk > (imagine a semantic difference between `obj.method` and > `(obj.method)`). But that's not what I was talking about. I was talking about difference between `obj.method()` and `(obj.method)()`, but you in your recent emails keep reducing that to `obj.method` and `(obj.method)`. Sorry, but you can't just drop those parens at the end, they have the specific meaning (a call). And I initially optimized presentation for number of characters with examples like "a.b()", but perhaps I should have written "a.b(foo, bar, baz)", so the "(foo, bar, baz)" part was big and pronounced and there was no desire to drop it silently. > Your mistake was comparing `(obj.method)()` with `a + (b + c)` when > you should have compared it to `(a + b) + c`. No, the comparison was to show that placing parens *does* already change semantic meaning of operator sequences. The example could only confuse you if you try to compare chalk and cheese, sorry, "+" and method call, directly. They behave in regard to parens *similarly*, but not *exactly*, how you might have thought. > Not every source code > difference has a semantic difference: > > x = 1 > x=1 > x = 1 > x = 1 or None > x = (1) > > all mean the same thing. Putting parens around the final (1) changes > nothing. Yeah, but imagine if parens were put like: x(= 1). That would completely change the meaning. Like, it would become SyntaxError in current Python, but that actually means we could assign a new meaning to it! Indeed, how many proposals to use up that syntax we had here on python-ideas? 1, 2, 3? Zero you say? Oh, I'm sure someone will accept the challenge ;-). For example, I believe we had proposals for syntax like x(a=) already, no? > Let's get away from using round brackets for function call, because > it clashes with the use of round brackets for grouping. I wouldn't say they "clash". They are completely disambiguated syntax-wise. But based on the discussion we have here, it's fair to say that some people get confused seeing parens with different meaning together, for example you keep dropping one of the parens pair ;-). > All we really > need is a *postfix unary operator*. Warm! I'd even say "hot", but I know it won't click, even with the following clarifications: 1. Function call is not a postfix unary operator. It's binary operator. It's syntax is: expr(args) 2. It's not even an infix operator, like for example "+". You can't really ignore that closing paren - without it, the syntax is invalid. So, function call operator, "()" is such a funky operator which is "spread around" the new expression it forms. > x() # the brackets are "postfix unary zero-argument function > call" > > Let's use the factorial operator, "bang" `!` instead. > > obj.attr! > > has to be evaluated from left to right under Python's rules. You > can't apply the factorial operator until you have looked up attr on > obj, and you cannot lookup attr until you have looked up obj. Sounds good, for as long as they're separate operators. But look at the conditional Python operator: foo if bar else baz Getting warmer, no? > So the only possible order of operations is left to right. This is > not meaningful: > > # attr factorial first, then lookup obj, then the dot lookup > obj.(attr!) > > but while this is meaningful, the order of operations is unchanged: > > # lookup obj first, then dot lookup attr, then factorial > (obj.attr)! > > Replace the factorial postfix operator with the `()` call operator, > and the logic remains the same. No necessarily. Some operators are less simple than the others. Let the conditional operator be the witness. > -- > Steve [] -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HJOGHL6457EGPHNPOHSTYJP4RWNDR63P/ Code of Conduct: http://python.org/psf/codeofconduct/
