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/