Hello, 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: > > 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. 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. That's in striking difference to "a.b()", which calls the *method* "b" of object held in variable "a". > > 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? In a sense I don't. I intend to make very fine-grained, finely cut semantic *adjustments*, with a motive of being able to implement the semantics more efficiently, and with a constraint that program valid under the new semantics is also valid (and have the same effect) under the old. Again, this is continuation of the effort previously presented in https://mail.python.org/archives/list/python-ideas@python.org/thread/KGN4Q2EMOMGHLMUH4ITJB4ES7NR3FSB7/ where you can assess yourself how successful the "also valid under old" part was so far. For indeed, that's the distinguishing trait of how my effort differs from some (many?) other efforts, for example the Prothon project that you quoted. Where people start with already rather distinct than Python ideas, and then can't resist to diverge more, and more, and more. Whereas I try (with an aspiration to be pretty thorough) to make as little changes as possible to achieve the desired effect (which is the ability to write more efficient Python programs, not inventing a new language!) > > I'm still confused. > > -- > Greg -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/N4CYM4QWTUFD7ESQ25MWLPXEBF2NWRSP/ Code of Conduct: http://python.org/psf/codeofconduct/
