<div dir="auto">The time machine is used again! We HAVE a spelling: @functions.lru_cache()<div dir="auto"><br></div><div dir="auto">The problem is that there's still a time/space trade-off. If you might call a (pure) function with millions of different values, you likely don't want to cache them all. The current spelling makes this configurable, but there's no universal right answer.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 14, 2018, 8:36 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm hoping that the arguments for assignment expressions will be over by <br>
Christmas *wink* so as a partial (and hopefully less controversial) <br>
alternative, what do people think of the idea of flagging certain <br>
expressions as "pure functions" so the compiler can automatically cache <br>
results from it?<br>
<br>
Let me explain: one of the use-cases for assignment expressions is to <br>
reduce repetition of code which may be expensive. A toy example:<br>
<br>
  func(arg) + func(arg)*2 + func(arg)**2<br>
<br>
If func() is a pure function with no side-effects, that is three times <br>
as costly as it ought to be:<br>
<br>
  (f := func(arg)) + f*2 + f**2<br>
<br>
Functional languages like Haskell can and do make this optimization all <br>
the time (or so I am lead to believe), because the compiler knows that <br>
func must be a pure, side-effect-free function. But the Python <br>
interpreter cannot do this optimization for us, because it has no way of <br>
knowing whether func() is a pure function.<br>
<br>
Now for the wacky idea: suppose we could tell the interpreter to cache <br>
the result of some sub-expression, and re-use it within the current <br>
expression? That would satisfy one use-case for assignment operators, <br>
and perhaps weaken the need for := operator.<br>
<br>
Good idea? Dumb idea?<br>
<br>
Good idea, but you want the assignment operator regardless?<br>
<br>
I don't have a suggestion for syntax yet, so I'm going to make up syntax <br>
which is *clearly and obviously rubbish*, a mere placeholder, so don't <br>
bother telling me all the myriad ways it sucks. I know it sucks, that's <br>
deliberate. Please focus on the *concept*, not the syntax.<br>
<br>
We would need to flag which expression can be cached because it is PURE, <br>
and tag how far the CACHE operates over:<br>
<br>
  <BEGIN CACHE> <br>
    <PURE><br>
      func(arg)<br>
    <END PURE> <br>
    + func(arg)*2 + func(arg)**2 <br>
  <END CACHE><br>
<br>
This would tell the compiler to only evaluate the sub-expression <br>
"func(arg)" once, cache the result, and re-use it each other time it <br>
sees that same sub-expression within the surrounding expression.<br>
<br>
To be clear: it doesn't matter whether or not the sub-expression <br>
actually is pure. And it doesn't have to be a function call: it could be <br>
anything legal in an expression.<br>
<br>
If we had this, with appropriately awesome syntax, would that negate the <br>
usefulness of assignment expresions in your mind?<br>
<br>
<br>
<br>
-- <br>
Steve<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank" rel="noreferrer">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>