> On 23 Jun 2022, at 08:27, Stephen J. Turnbull <stephenjturnb...@gmail.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. > > Probably. > >> The simple >> >> 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. Barry > _______________________________________________ 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/DEBOPY6OIRRLLCO2SQDYXXM7UMXZYRMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
