On 18/12/20 1:52 am, Paul Sokolovsky wrote:
On Fri, 18 Dec 2020 01:23:34 +1300
Greg Ewing <greg.ew...@canterbury.ac.nz> 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
_______________________________________________
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/7B35CV52SA3VG43BU54PHTGJFOSNRALL/
Code of Conduct: http://python.org/psf/codeofconduct/
