[Python-ideas] Bad programming style in decorators?

Guido van Rossum guido at python.org
Sat Jan 2 22:34:48 EST 2016


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 at 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
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160102/14a23b58/attachment.html>


More information about the Python-ideas mailing list