On 17/12/20 8:16 am, Paul Sokolovsky wrote:
With all the above in mind, Python3.7, in a strange twist of fate, and
without much ado, has acquired a new operator: the method call, ".()".

> CPython3.6 and below didn't have ".()" operator, and compiled it as
> "attr access" + "function call", but CPython3.7 got the new operator,
> and compiles it as such (the single operator).

Um, no. There is no new operator. You're reading far more into the
bytecode change than is actually there.

So, why CPython3.7+ still compiles "(a.b)()" using LOAD_METHOD.

Because a.b() and (a.b)() have the same semantics, *by definition*.
That definition has NOT changed. Because they have the same
semantics, there is no need to generate different bytecode for them.

But still, are there Python implementations which compile "(a.b)()"
faithfully, with its baseline semantic meaning? Of course there're.
E.g., MicroPython-derived Python implementations compile it in the full
accordance with the theory presented here:

All that means is that Micropython is missing a potential
optimisation. This is probably a side effect of the way its
parser and code generator work, rather than a conscious decision.

Now, it's quite possible to imagine a language in which
a.b() and (a.b)() mean different things. Does anyone remember
Prothon? (It's a language someone was trying to design a while
back that was similar to Python but based on prototypes
instead of classes.)

A feature of Prothon was that a.b() and t = a.b; t() would do
quite different things (one would pass a self argument and the
other wouldn't).

I considered that a bad thing. I *like* the fact that in Python
I can use a.b to get a bound method object and call it later,
with the same effect as if I'd called it directly.

I wouldn't want that to change. Fortunately, it never will,
because changing it now would break huge amounts of code.

--
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/XG6U6NAWWBNDWPHPM54WUPUVWKKU5IQL/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to