If you want more discussion please discuss a specific example, showing the decorator code itself (not just the decorator call).

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.

On Sat, Jan 2, 2016 at 8:00 PM, u8y7541 The Awesome Person <surya.subbarao1@gmail.com> wrote:

The wrapper functions themselves, though, exist in a one:one
correspondence with the functions they're applied to - when you apply
functools.lru_cache to a function, the transient decorator produced by
the decorator factory only lasts as long as the execution of the
function definition, but the wrapper function lasts for as long as the
wrapped function does, and gets invoked every time that function is
called (and if a function is performance critical enough for the
results to be worth caching, then it's likely performance critical
enough to be thinking about micro-optimisations). (Nick Coghlan)
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.

But, as I explained, the function will _not_ be redefined and trashed every frame; it will be created one time. (Andrew Barnert)
Hmm... Nick says different...

This all suggests that if your application is severely memory
constrained (e.g. it's running on an embedded interpreter like
MicroPython), then it *might* make sense to incur the extra complexity
of using classes with a custom __call__ method to define wrapper
functions, over just using a nested function. (Nick Coghlan)

Yes, I was thinking of that when I started this thread, but this thread is just from my speculation. 

-Surya Subbarao

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

--Guido van Rossum (python.org/~guido)