<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 28, 2017 at 8:54 AM, M.-A. Lemburg <span dir="ltr"><<a href="mailto:mal@egenix.com" target="_blank">mal@egenix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28.02.2017 17:35, David Mertz wrote:<br>
> Clearly there is SOME semantics that is consistent and coherent since many<br>
> languages have either a lazy or eager declaration syntax, with different<br>
> defaults between languages but both being built in. There are a lot of<br>
> ways that Python isn't Haskell, obviously. But both Scheme and OCaml are<br>
> eager by default with a lazy declaration (and Haskell or Miranda have an<br>
> eager declaration correspondingly).<br>
><br>
> It might be worth looking at their semantics in the PEP.<br>
<br>
</span>Scheme, for example, uses an explicit approach to turning<br>
a promise into a value:<br>
<br>
<a href="http://www.shido.info/lisp/scheme_lazy_e.html" rel="noreferrer" target="_blank">http://www.shido.info/lisp/<wbr>scheme_lazy_e.html</a><br>
<br>
This makes a lot of sense, but you can already have the<br>
same in Python using generators.<br></blockquote><div><br></div><div>I think the closer equivalent is a lambda. And it's quite true that Scheme's `force` is pretty much the same thing as making a call to the lambda later. E.g.</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><font face="monospace, monospace">def force(x):</font></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><font face="monospace, monospace"> if callable(x):</font></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><font face="monospace, monospace"> return x()</font></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><font face="monospace, monospace"> else:</font></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><font face="monospace, monospace"> return x</font></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In Python we only have pass by value (parameters to functions<br>
get pushed onto the VM stack). Pass by name can also be had,<br>
but requires explicit indirection, e.g. by using a generator<br>
as wrapper.</blockquote></div><div class="gmail_extra"><br></div>I wouldn't want to change pass-by-value semantics. What I imagine instead is a new type `lazy` or `delayed` or `deferred` (whatever spelling). Delayed objects would have that type, and access to objects would need to do an implementation-level call to a "_force" that looks something like:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><font face="monospace, monospace">def _force(x):</font></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><font face="monospace, monospace"> if isinstance(x, delayed):</font></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><font face="monospace, monospace"> return _concretize(x)</font></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><font face="monospace, monospace"> else:</font></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><font face="monospace, monospace"> return x</font></div></blockquote><div><br></div><div>I <i>do</i> see the obvious likely problem here. Object access is perhaps the most common thing that happens in Python, and adding a new conditional check to every one of those could very well slow down all the non-lazy behavior far too much.</div><div><br></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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>