On 23 Jun 2022, at 08:27, Stephen J. Turnbull email@example.com wrote:
Barry Scott writes:
I can think of ways to implement evaluation-on-reference, but they all have the effect of making python slower.
a = b
will need to slow down so that the object in b can checked to see if it need evaluating.
No, it doesn't. Binding a name is special in many ways, why not this one too? Or "a = a" could be the idiom for "resolve a deferred now", which would require the check for __evaluate_me_now__ as you say. But such simple "a = b" assignments are not so common that they would be a major slowdown. I would think the real problem would be the "oops" of doing "a = b" and evaluating a deferred you don't want to evaluate. But this isn't a completely new problem, it's similar to a = b =  and expecting a is not b.
Interest idea that ref does not auto evaluate in all cases. I was wondering about what the compile/runtime can do it avoid the costs of checking for an evaluation.
Now consider a = b + 0. b.__add__ will be invoked in the usual way. Only if b is a deferred will evaluation take place.
But the act of checking if b is deferred is a cost I am concerned about.
So I don't really see the rest of Python slowing down much.
Once we have the PEP address it’s semantics in detail we can estimate the costs.
I would think that it’s not that hard to add the expected check into the python ceval.c And benchmark the impact of the checks. This would not need a full implementation of the deferred mechanism.