<div dir="ltr"><div dir="auto">I don't think you have to make a special case for iteration.<div dir="auto"><br></div><div dir="auto">When the interpreter hits:</div><div dir="auto"><font face="monospace, monospace">>>> print(x1)</font></div><div dir="auto"><br></div><div dir="auto">print falls under I/O, so it forces evaluation of x1, so we back-track to where x1 is evaluated:</div><div dir="auto"><font face="monospace, monospace">>>> x1 = next(xs)</font></div><div dir="auto"><br></div><div dir="auto">And in the next call, we find that we must evaluate the state of the iterator, so we have to back-track to:</div><div dir="auto"><font face="monospace, monospace">>>> x0 = next(xs)</font></div><div dir="auto"><br></div><div dir="auto">Evaluate that, then move forward.<br><br>You essentially keep a graph of pending/unevaluated expressions linked by their dependencies and evaluate branches of the graph as needed. You need to evaluate state to navigate conditional branches, and whenever state is passed outside of the interpreter's scope (like I/O or multi-threading). I think problems might crop up in parts of the language that are pure c-code. For instance; I don't know if the state variables in a list iterator are actually visible to the Interpreter or if it's implemented in C that is inscrutable to the interpreter.</div><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Mar 2, 2017 5:54 PM, "Joseph Jevnik" <<a href="mailto:joejev@gmail.com" target="_blank">joejev@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_8790139901657670528quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Other things that scrutinize an expression are iteration or branching (with the current evaluation model). If `xs` is a thunk, then `for x in xs` must scrutinize `xs`. At first this doesn't seem required; however, in general `next` imposes a data dependency on the next call to `next`. For example:<br><br></div>x0 = next(xs)<br></div><div>x1 = next(xs)<br><br></div><div>print(x1)<br></div><div>print(x0)<br><br></div><div>If `next` doesn't force computation then evaluating `x1` before `x0` will bind `x1` to `xs[0]` which is not what the eager version of the code does.<br></div><div><br></div><div>To preserve the current semantics of the language you cannot defer arbitrary expressions because they may have observable side-effects. Automatically translating would require knowing ahead of time if a function can have observable side effects, but that is not possible in Python. Because it is impossible to tell in the general case, we must rely on the user to tell us when it is safe to defer an expression.<br></div></div><div class="m_8790139901657670528elided-text"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 2, 2017 at 6:42 PM, Abe Dillon <span dir="ltr"><<a href="mailto:abedillon@gmail.com" target="_blank">abedillon@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"><span style="font-size:12.8px">I'm going to repeat here what I posted in the thread on lazy imports.<br>If it's possible for the interpreter to determine when it needs to force evaluation of a lazy expression or statement, then why not use them everywhere? If that's the case, then why not make everything lazy by default? Why not make it a service of the language to lazify your code (analogous to garbage collection) so a human doesn't have to worry about screwing it up?<br><br>There are, AFAIK, three things that *must* force evaluation of lazy expressions or statements:</span><div><span style="font-size:12.8px"><br>1) Before the GIL is released, all pending lazy code must be evaluated since the current thread can't know what variables another thread will try to access (unless there's a way to explicitly label variables as "shared", then it will only force evaluation of those).<br><br>2) Branching statements force evaluation of anything required to evaluate the conditional clause.<br><br>3) I/O forces evaluation of any involved lazy expressions.<br><br></span></div></div><div class="m_8790139901657670528m_3938465170859780454HOEnZb"><div class="m_8790139901657670528m_3938465170859780454h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 20, 2017 at 7:07 PM, Joshua Morton <span dir="ltr"><<a href="mailto:joshua.morton13@gmail.com" target="_blank">joshua.morton13@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">This comes from a bit of a misunderstanding of how an interpreter figures out what needs to be compiled. Most (all?) JIT compilers run code in an interpreted manner, and then compile subsections down to efficient machine code when they notice that the same code path is taken repeatedly, so in pypy something like <div><br></div><div> x = 0</div><div> for i in range(100000):</div><div> x += 1</div><div><br></div><div>would, get, after 10-20 runs through the loop, turned into assembly that looked like what you'd write in pure C, instead of the very indirection and pointer heavy code that such a loop would be if you could take it and convert it to cpython actually executes, for example. So the "hot" code is still run.</div><div><br></div><div>All that said, this is a bit of an off topic discussion and probably shouldn't be on list.</div><div><br></div><div>What you really do want is functional purity, which is a different concept and one that python as a language can't easily provide no matter what.</div><div><br></div><div>--Josh</div></div><div class="m_8790139901657670528m_3938465170859780454m_1389153043813734907HOEnZb"><div class="m_8790139901657670528m_3938465170859780454m_1389153043813734907h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 20, 2017 at 7:53 PM Abe Dillon <<a href="mailto:abedillon@gmail.com" target="_blank">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="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><span style="color:rgb(80,0,80);font-size:12.8px" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">On Fri, Feb 17, 2017, Steven D'Aprano wrote:<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"></span><blockquote class="gmail_quote m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">JIT compilation delays *compiling* the code to run-time. This is a</span><br style="font-size:12.8px" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><span style="font-size:12.8px" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">proposal for delaying *running* the code until such time as some other</span><br style="font-size:12.8px" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><span style="font-size:12.8px" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">piece of code actually needs the result.</span></blockquote></div><div dir="ltr" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><div class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">My thought was that if a compiler is capable of determining what needs to be compiled just in time, then an interpreter might be able to determine what expressions need to be evaluated just when their results are actually used.<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">So if you had code that looked like:<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">>>> log.debug("data: %s", expensive())<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">The interpreter could skip evaluating the expensive function if the result is never used. It would only evaluate it "just in time". This would almost certainly require just in time compilation as well, otherwise the byte code that calls the "log.debug" function would be unaware of the byte code that implements the function.<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">This is probably a pipe-dream, though; because the interpreter would have to be aware of side effects.<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"></div></div><div class="gmail_extra m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><div class="gmail_quote m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">On Mon, Feb 20, 2017 at 5:18 AM, <span dir="ltr" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><<a href="mailto:tritium-list@sdamon.com" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">tritium-list@sdamon.com</a>></span> wrote:<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><blockquote class="gmail_quote m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> -----Original Message-----<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> From: Python-ideas [mailto:<a href="mailto:python-ideas-bounces%2Btritium-" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">python-ideas-bounces+t<wbr>ritium-</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> list=<a href="mailto:sdamon.com@python.org" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">sdamon.com@python.org</a>] On Behalf Of Michel Desmoulin<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> Sent: Monday, February 20, 2017 3:30 AM<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> To: <a href="mailto:python-ideas@python.org" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">python-ideas@python.org</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> Subject: Re: [Python-ideas] Delayed Execution via Keyword<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> I wrote a blog post about this, and someone asked me if it meant<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> allowing lazy imports to make optional imports easier.<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> Someting like:<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> lazy import foo<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> lazy from foo import bar<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> So now if I don't use the imports, the module is not loaded, which could<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> also significantly speed up applications starting time with a lot of<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> imports.<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
</span>Would that not also make a failure to import an error at the time of<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
executing the imported piece of code rather than at the place of import?<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
And how would optional imports work if they are not loaded until use? Right<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
now, optional imports are done by wrapping the import statement in a<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
try/except, would you not need to do that handling everywhere the imported<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
object is used instead?<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
(I haven't been following the entire thread, and I don't know if this is a<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
forest/tress argument)<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<div class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791m_4963579814170615314HOEnZb m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><div class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791m_4963579814170615314h5 m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> ______________________________<wbr>_________________<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> Python-ideas mailing list<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> <a href="mailto:Python-ideas@python.org" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">Python-ideas@python.org</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
______________________________<wbr>_________________<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
Python-ideas mailing list<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<a href="mailto:Python-ideas@python.org" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">Python-ideas@python.org</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
</div></div></blockquote></div><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg"></div>
______________________________<wbr>_________________<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
Python-ideas mailing list<br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<a href="mailto:Python-ideas@python.org" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">Python-ideas@python.org</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg">
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" class="m_8790139901657670528m_3938465170859780454m_1389153043813734907m_-1021335186385616791gmail_msg" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a></blockquote></div>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br></blockquote></div><br></div>
</div></blockquote></div><br></div></div>
</div>