<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, 17 Feb 2017 at 21:57 Joseph Jevnik <<a href="mailto:joejev@gmail.com">joejev@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"><div class="gmail_msg">> You should be able to pass the result to *any* existing code that 
expects a function and sometimes calls it, and the function should be 
called when that happens, rather than evaluated to a delayed object and 
then discarded.<br class="gmail_msg"><br class="gmail_msg"></div></div><div dir="ltr" class="gmail_msg">I disagree with this claim because I do not think that you should have side effects and delayed execution anywhere near each other.</div></blockquote><div><br></div><div>If Python gets delayed execution, it's going to be near side effects. That's just the reality we live in.</div><div> </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">You only open youself up to a long list of special cases for when and where things get evaluated.</div></blockquote><div><br></div><div>Not really. With the function call example, as long as x() always evaluates x (rather than becoming a delayed call to x), we're all good. Remember that this has nothing to do with the contents of x, which indeed shouldn't use delays if it cares about side effects—what might be delayed here is the expression that finds x. </div></div></div>