<p dir="ltr">On May 2, 2016 7:55 AM, "Robert van Geel" <<a href="mailto:robert@bign.nl">robert@bign.nl</a>> wrote:<br>
><br>
> I'm receiving digests and seem to not have each individual mail, so here's a digested response:<br>
><br>
> One side of this that's not discussed is the possible optimization. I can imagine if you've got a lot of objectproperty write and -reads this could actually make certain use cases a lot faster such as this one, saving 6 opcodes:<br>
><br>
> def __init__(self, left, top, width, height, content):<br>
>     self.left = left<br>
>     self.top = top<br>
>     self.width = width<br>
>     self.height = height<br>
>     self.content = content.upper()<br>
>     self.decideColors()<br>
>     self.draw()<br>
><br>
> versus:<br>
><br>
> def __init__(self, left, top, width, height, content):<br>
>     with self:<br>
>         .left = left<br>
>         .top = top<br>
>         .width = width<br>
>         .height = height<br>
>         .content = content.upper()<br>
>         .decideColors()<br>
>         .draw()<br>
><br>
> The suggestion that you could accomplish this with a (peephole) optimizer does not seem quite correct to me:<br>
><br>
> x = myobject.b()<br>
> ...<br>
> z = myobject.c()<br>
><br>
> does not necessarily have a consistent pointer to myobject although it would require some acrobatics to change them in a way that can not be seen by an optimizer.<br>
> You can think about exec() or even another thread intervening into a generator function, not something I would do but who knows.</p>
<p dir="ltr">It's actually part of CPython's current semantics that local variables cannot be modified via stack introspection exactly because it allows certain optimizations. You can read them, it might look like you can touch them (you can get access to what's allegedly the real dict of locals), but this is an illusion: modifications to that dict are not reflected back to the running code. See PyFrame_LocalsToFast and vice versa. So teaching the peephole optimizer to do this would be legal afaict.</p>
<p dir="ltr">I'd be surprised and interested to see an example where those 6 opcodes made any non-trivial difference to a real program though -- thanks to the above-mentioned optimizations, accessing a local variable is already one of CPython's fastest operations.</p>
<p dir="ltr">-n</p>