<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 17, 2017 at 5:23 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
try:<br>
    Aardvark<br>
except NameError:<br>
    from backport import Aardvark<br>
<br>
No such thing is possible for new syntax. So that counts as a<br>
disadvantage of new syntax. Are we positive that there *must* be new<br>
syntax to solve this problem?<br></blockquote><div><br></div><div>I agree it counts as a disadvantage.  But Dask and lazy, and even just using lambdas as "thunks" push what we can do as far as we can without syntax.  Those will always require a `obj.compute()` or `obj()` or `eval(obj)` or something else like that to force the "thunk" to concretize.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span style="font-size:11.2px">I think side-effects is a red herring. The obvious rule is: side-effects</span><br style="font-size:11.2px"><span style="font-size:11.2px">occur when the delayed thunk is reified. If you care about the actual</span><br style="font-size:11.2px"><span style="font-size:11.2px">timing of the side-effects, then don't use delayed evaluation. If you</span><br style="font-size:11.2px"><span style="font-size:11.2px">don't care, then who cares if the side-effect is delayed?</span></div></blockquote><div><br></div><div>Exactly! The same rule applies when writing any computational functions too.  If you worry whether they are pure, don't have side effects.  Or if you don't care about the side-effects too much (for example, when or if they happen specifically), that's fine and accept it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> So far I'm going with pretty much anything that isn't being the right-hand<br></div><span class="gmail-">
> of an assignment. So coercion to different types, hashing (for use as a key<br>
> in a dict or set), __repr__, etc would all be covered, as well as identity<br>
> and comparisons. i.e.:<br>
</span>[...]<br><br>
That will make it pretty much impossible to tell whether something is a<br>
delayed "thunk" or not, since *any* attempt to inspect it in any way<br>
will cause it to reify. Maybe that's what we want.</blockquote><div> </div><div>This feels like a disadvantage, and an important one.  Most "normal" programmers should never have to care whether something is delayed or has been concretized already.  But people writing debuggers, profilers, etc. really do want to know.</div><div><br></div><div>There should be some way at poking at an object if you really want to without concretizing it.  I wouldn't care if this was some ugly and obscure device like 'inspect._is_delayed(my_obj._co_delayed)' that has different semantics than other function calls.  Maybe "the uglier the better" in this case, since it *should* be reserved for special purposes only.</div><div> </div></div>-- <br><div class="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons.  Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</div></div>