<div dir="ltr"><div>If you want more discussion please discuss a specific example, showing the decorator code itself (not just the decorator call).<br><br></div>The upshot is that creating a function object is pretty efficient and probably more efficient than instantiating a class -- if you don't believe that write a micro-benchmark.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 2, 2016 at 8:00 PM, u8y7541 The Awesome Person <span dir="ltr"><<a href="mailto:surya.subbarao1@gmail.com" target="_blank">surya.subbarao1@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">The wrapper functions themselves, though, exist in a one:one<br>
correspondence with the functions they're applied to - when you apply<br>
functools.lru_cache to a function, the transient decorator produced by<br>
the decorator factory only lasts as long as the execution of the<br>
function definition, but the wrapper function lasts for as long as the<br>
wrapped function does, and gets invoked every time that function is<br>
called (and if a function is performance critical enough for the<br>
results to be worth caching, then it's likely performance critical<br></span>
enough to be thinking about micro-optimisations). (Nick Coghlan)</blockquote><div> </div></div>Yes, that is what I was thinking of. Just like Quake's fast inverse square root. Even though it is a micro-optimization, it greatly affects how fast the game runs.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">But, as I explained, the function will _not_ be redefined and trashed every frame; it will be created one time. (Andrew Barnert)</span></blockquote><div> </div><div>Hmm... Nick says different...</div><div><br style="font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><span style="font-size:12.8px">This all suggests that if your application is severely memory<br></span><span style="font-size:12.8px">constrained (e.g. it's running on an embedded interpreter like<br></span><span style="font-size:12.8px">MicroPython), then it *might* make sense to incur the extra complexity<br></span><span style="font-size:12.8px">of using classes with a custom __call__ method to define wrapper<br></span></span><span style="font-size:12.8px">functions, over just using a nested function. (Nick Coghlan)</span></blockquote><div><br></div><div>Yes, I was thinking of that when I started this thread, but this thread is just from my speculation. </div></div><span class="HOEnZb"><font color="#888888"><div><br></div><div class="gmail_extra"><div><br></div>-- <br><div><div dir="ltr"><font face="garamond, serif" size="6">-Surya Subbarao</font></div></div>
</div></font></span></div>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="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" target="_blank">http://python.org/psf/codeofconduct/</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>