On 18/12/20 1:52 am, Paul Sokolovsky wrote:
On Fri, 18 Dec 2020 01:23:34 +1300 Greg Ewing
wrote: On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
a) (a.b)() syntax b) apply() being resurrected
I can't answer that without knowing what alternative semantics you have in mind for (a.b)(). You haven't really explained that yet.
But I did by now, and you didn't need to wait for me to do it, because "(a.b)()" does *exactly* what *you* or anybody else would think it does, based on your knowledge of what grouping parens in the expressions do. So again, "(a.b)()" first extracts a value of the "b" *attribute* from the object held in variable "a", then calls that value with 0 arguments.
We're going round in circles. Are we talking about current Python semantics, or proposed new semantics? Please just give us a clear answer on that. If we're talking about current semantics, then my knowledge of what grouping parens do (which is based on what the Python docs define them to do) means that a.b() and (a.b)() are just different ways of writing *exactly* the same thing.
That's in striking difference to "a.b()", which calls the *method* "b" of object held in variable "a".
No, it doesn't. It calls *whatever* object a.b returns. It only calls a method if b happens to be a method. It might not be. It might be a callable object stored in an instance attribute, or a function stored in a module attribute, in which case the very same syntax is just an ordinary call, not a method call. That last case is something you might want to ponder. The same LOAD_METHOD/CALL_METHOD bytecode sequence is being executed, yet it's *not* performing a method call! How does your new improved theory of method calls explain *that*?
In a sense I don't. I intend to make very fine-grained, finely cut semantic *adjustments*
If you come back when you've figured out exactly what those adjustments will be and are able to explain them clearly, we will have something to talk about. -- Greg