On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
CPython compiles "(a.b)()" using LOAD_METHOD not because it consciously "optimizes" it, but simply because it's *unable* to represent the difference between "a.b()" and "(a.b)()".
I'm pretty sure whoever added the optimisation fully intended it to apply to (a.b)() as well as a.b() -- given that they are supposed to have the same semantics, why would you *not* want to optimise both? So even if the AST were able to distinguish between them, there would be no reason to do so. Your alternative theory would be of use if you wanted to change the semantics of (a.b)(). But the semantics need to be defined first, then you make the AST and code generation whatever it needs to be to support those semantics.
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.
We just discussed the pillar #1 of the strict mode, part 2. For that pillar being the separation between methods and attributes.
What's interesting, that part 2, just like part 1, of the strict mode doesn't really make any "revolutionary" changes. It just exposes, emphasizes, and makes consistent, the properties Python language already has. Ain't that cute? Do you spot any issues, Greg?
So you *don't* intend to make any semantic changes? I'm still confused. -- 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/G7BMV2FLAZBTSY4ITI7G3DWJPZ6XWQQP/ Code of Conduct: http://python.org/psf/codeofconduct/
