<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hey! Excellent feedback!</div><div><br></div><div>In my mind, which word is selected doesn't matter much to me. I think the technical term is 'thunk'? I think delayed is most clear. </div><div><br></div><div>I'm not sure if eager execution is so common in this framework it needs its own keyword. Notably, default Python will handle that case</div><div><br></div><div>x= Delayed: sum((foo.inc(), foo.inc()))</div><div>Can become</div><div>y=foo.inc()</div><div>x= delayed: sum((foo.inc(), y))</div><div><br></div><div>It's less sugary, but seems ok to me. How does that seem?</div><div><br>-Joseph</div><div><br>On Feb 17, 2017, at 1:55 PM, Joshua Morton <<a href="mailto:joshua.morton13@gmail.com">joshua.morton13@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I did some quick thinking and a bit of research about some aspects of this proposal:<div><br></div><div>There are a number of keyword options (delay, defer, lazy, delayed, deferred, etc.), a quick look through github says that of these, "deferred" seems to be the least used, but it still comes up quite a lot (350K times, lazy appears over 2 million). That's unfortunate, but I'm wondering how common async and await were when that was proposed and accepted?</div><div><br></div><div>Another potential pitfall I'm realizing now (and apologies if this is unnecessary bikeshedding) is that this may require another keyword. If I understand the proposal correctly, at this point the suggestion is that `delayed <EXPR>` delays the evaluation of EXPR until it is requested in a non-delayed context. That is</div><div><br></div><div> >>> x = delayed 1 + 2</div><div> >>> y = delayed 3 + 4</div><div> >>> z = delayed x + y # neither x nor y has been evaluated yet</div><div> >>> z</div><div> 10</div><div><br></div><div>This works fine for simple cases, but there might be situations where someone wants to control evaluation a bit more. As soon as we add any kind of state things get icky:</div><div><br></div><div> # assuming Foo is a class an attribute `value` and a method </div><div> # `inc` that increments the value and returns the current value</div><div> >>> foo = Foo(value=0)</div><div> >>> x = delayed sum([foo.inc(), foo.inc()])</div><div> >>> foo.inc()</div><div> 1</div><div> >>> x</div><div> 5</div><div><br></div><div>However, assuming this is a real, more complex system, we might want a way to have one or both of those inc calls be eagerly evaluated, which requires a way of signalling that in some way:</div><div><br></div><div> >>> foo = Foo(value=0)</div><div> >>> x = delayed sum([foo.inc(), eager foo.inc()])</div><div> >>> foo.inc()</div><div> 2</div><div> >>> foo.inc()</div><div> 4</div><div><br></div><div>Perhaps luckily, `eager` is less commonly used than even `delayed`, but still 2 keywords is an even higher bar. I guess another alternative would be to require annotating all subexpressions with `delayed`, but then that turns the above into</div><div><br></div><div><div> >>> foo = Foo(value=0)</div><div> >>> x = delayed sum([delayed foo.inc(), delayed foo.inc()])</div><div> >>> foo.inc()</div><div> 1</div><div> >>> x</div><div> 5</div></div><div><br></div><div>At which point `delayed` would need to be a much shorter keyword (the heathen in me says overload `del`).</div><div><br></div><div>--Josh</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 17, 2017 at 12:13 PM Abe Dillon <<a href="mailto:abedillon@gmail.com">abedillon@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Actually, following from the idea that packing and unpacking variables should be delayed by default, it might make sense to use syntax like:<br class="gmail_msg"><br class="gmail_msg">>>> a = *(2+2)<br class="gmail_msg">>>> b = a + 1<br class="gmail_msg"><br class="gmail_msg">Instead of<br class="gmail_msg"><br class="gmail_msg">>>> a = lazy 2+2 # or whatever you want the keyword to be<br class="gmail_msg">>>> b = a + 1<br class="gmail_msg"><br class="gmail_msg">That syntax sort-of resembles generator expressions, however; I usually like how python favors actual words over obscure symbol combinations for readability's sake.</div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Fri, Feb 17, 2017 at 10:57 AM, Abe Dillon <span dir="ltr" class="gmail_msg"><<a href="mailto:abedillon@gmail.com" class="gmail_msg" target="_blank">abedillon@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">I'd like to suggest a shorter keyword: `lazy`<br class="gmail_msg"><br class="gmail_msg">This isn't an endorsement. I haven't had time to digest how big this change would be.<br class="gmail_msg"><br class="gmail_msg">If this is implemented, I'd also like to suggest that perhaps packing and unpacking should be delayed by default and not evaluated until the contents are used. It might save on many pesky edge cases that would evaluate your expression unnecessarily.</div><div class="m_-1414358653002897841HOEnZb gmail_msg"><div class="m_-1414358653002897841h5 gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Fri, Feb 17, 2017 at 10:43 AM, Joseph Hackman <span dir="ltr" class="gmail_msg"><<a href="mailto:josephhackman@gmail.com" class="gmail_msg" target="_blank">josephhackman@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Agreed. I think this may require some TLC to get right, but posting here for feedback on the idea overall seemed like a good start. As far as I know, the basic list and dict do not inspect what they contain. I.e.<br class="gmail_msg">
<br class="gmail_msg">
d = {}<br class="gmail_msg">
d['a']= delayed: stuff()<br class="gmail_msg">
b=d['a']<br class="gmail_msg">
<br class="gmail_msg">
b would end up as still the thunk, and stuff wouldn't be executed until either d['a'] or b actually is read from.<br class="gmail_msg">
<span class="m_-1414358653002897841m_5841430610666752140HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><br class="gmail_msg">
-Joseph<br class="gmail_msg">
</font></span><div class="m_-1414358653002897841m_5841430610666752140HOEnZb gmail_msg"><div class="m_-1414358653002897841m_5841430610666752140h5 gmail_msg"><br class="gmail_msg">
> On Feb 17, 2017, at 11:34 AM, Chris Angelico <<a href="mailto:rosuav@gmail.com" class="gmail_msg" target="_blank">rosuav@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
>> On Sat, Feb 18, 2017 at 3:29 AM, Joseph Hackman <<a href="mailto:josephhackman@gmail.com" class="gmail_msg" target="_blank">josephhackman@gmail.com</a>> wrote:<br class="gmail_msg">
>> ChrisA: I am not sure about collections. I think it may be fine to not special case it: if the act of putting it in the collection reads anything, then it is evaluated, and if it doesn't it isn't. The ideal design goal for this would be that all existing code continues to function as if the change wasn't made at all, except that the value is evaluated at a different time.<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
> Yeah, I'm just worried that it'll become useless without that. For<br class="gmail_msg">
> instance, passing arguments to a function that uses *a,**kw is going<br class="gmail_msg">
> to package your thunk into a collection, and that's how (eg) the<br class="gmail_msg">
> logging module will process it.<br class="gmail_msg">
><br class="gmail_msg">
> It's not going to be easy to have a simple AND useful definition of<br class="gmail_msg">
> "this collapses the waveform, that keeps it in a quantum state", but<br class="gmail_msg">
> sorting that out is fairly key to the proposal.<br class="gmail_msg">
><br class="gmail_msg">
> ChrisA<br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> Python-ideas mailing list<br class="gmail_msg">
> <a href="mailto:Python-ideas@python.org" class="gmail_msg" target="_blank">Python-ideas@python.org</a><br class="gmail_msg">
> <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br class="gmail_msg">
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" class="gmail_msg" target="_blank">http://python.org/psf/codeofconduct/</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Python-ideas mailing list<br class="gmail_msg">
<a href="mailto:Python-ideas@python.org" class="gmail_msg" target="_blank">Python-ideas@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br class="gmail_msg">
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" class="gmail_msg" target="_blank">http://python.org/psf/codeofconduct/</a><br class="gmail_msg">
</div></div></blockquote></div><br class="gmail_msg"></div>
</div></div></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
Python-ideas mailing list<br class="gmail_msg">
<a href="mailto:Python-ideas@python.org" class="gmail_msg" target="_blank">Python-ideas@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br class="gmail_msg">
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" class="gmail_msg" target="_blank">http://python.org/psf/codeofconduct/</a></blockquote></div>
</div></blockquote></body></html>