Function decorator having arguments is complicated

[Ethan Furman]

On 04/27, Chris Angelico wrote:
> On Mon, Apr 27, 2015 at 2:24 PM, Ethan Furman wrote:
> > On 04/27, Makoto Kuwata wrote:
> >>
> >> I feel that function decorator having arguments is complicated,
> >> because three 'def' are nested:
> >>
> >>   def multiply(n):
> >>     def deco(func):
> >>       def newfunc(*args, **kwargs):
> >>         return n * func(*args, **kwargs)
> >>       return newfunc
> >>     return deco
> >
> > When I have to write an argument-taking decorator, I use a class:
> >
> >     class multiply(object):  # don't need 'object in 3.x'
> >
> >         def __init__(self, n):
> >             self.n = n
> >
> >         def __call__(self, func):
> >             def newfunc(*args, **kwargs):
> >                 return self.n * func(*args, **kwargs)
> >             return newfunc
> 
> What's the advantage of that over a simple closure? You have the same
> number of nesting levels, plus a lot more boiler-plate repetition -
> instead of just referencing names from the outer scope, you have to
> explicitly capture them all with "self.n=n" for each one. I'm not sure
> you really even gain much clarity.
> 
> In a way, a closure is a short-hand for an object with a __call__
> method that auto-captures all its local variables.

I find it much easier to keep track of what is going on, especially in
those cases where there is pre-, post-, or both, processing going on.

YMMV.

--
~Ethan~