<div dir="ltr"><div>Delayed execution and respecting mutable semantics seems like a nightmare. For most indexers we assume hashability which implies immutability, why can't we also do that here? Also, why do we need to evaluate callables eagerly?<br><br></div>re the thunk replacing itself with the result instead of memoizing the result and living as an indirection: This is most likely impossible with the current memory model in CPython. Not all objects occupy the same space in memory so you wouldn't know how much space to allocate for the thunk. The interpreter has no way to find all the pointers in use so it cannot just do pointer cleanups to make everyone point to the newly allocated result.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 2:26 PM, Ed Kellett <span dir="ltr"><<a href="mailto:edk141@gmail.com" target="_blank">edk141@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">I think trying to eager-ify subexpressions is absurdly difficult to do right, and also a problem that occurs in other places in Python already, so solving it only for this new thing that might very well go no further is a bit odd.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I don't think versions that aren't transparent are much use.</div><span class=""><div class="gmail_quote"><br></div><div class="gmail_quote">> <span style="color:rgb(33,33,33);font-size:13px">Interesting. Okay. So in effect, these things aren't objects, they're</span></div><span style="color:rgb(33,33,33);font-size:13px">magic constructs that turn into objects the moment you do anything</span><br class="m_-3596132549104750871gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">with them, even an identity check. That makes sense.</span><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div></span><div><span style="color:rgb(33,33,33);font-size:13px">This seems unfortunate. Why not make these things objects that replace themselves with the evaluated-to object when they're used?</span></div><span class=""><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div><div><span style="color:rgb(33,33,33)">> </span><font color="#212121">"this collapses the waveform, that keeps it in a quantum state"</font></div><div><font color="#212121"><br></font></div></span><div><font color="#212121">That's a bit of a false dichotomy ;)</font></div><div><font color="#212121"><br></font></div><div><font color="#212121">I suggest that operators on delayed-objects defer evaluation iff all of their operands are delayed, with some hopefully-obvious exceptions:</font></div><div><font color="#212121">- Function call: delayed_thing() should evaluate delayed_thing</font></div><div><font color="#212121">- Attribute and item access should evaluate the container and key: even if both operands are delayed, in Python we have to assume things are mutable (especially if we don't know what they are yet), so we can't guarantee that delaying the lookup is valid.</font></div><div><font color="#212121"><br></font></div><div><font color="#212121">Just passing something to a function shouldn't collapse it. That'd make this completely useless.</font></div></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br></blockquote></div><br></div>