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/

Reply via email to