Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #89441
| References | <CAFTm5Ru5NbFOtLPoVSPujeakrGawdHXjNkWJOVs1XrvBNnOUOQ@mail.gmail.com> <20150427042426.GD32422@stoneleaf.us> |
|---|---|
| Date | 2015-04-27 14:32 +1000 |
| Subject | Re: Function decorator having arguments is complicated |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.35.1430109133.3680.python-list@python.org> (permalink) |
On Mon, Apr 27, 2015 at 2:24 PM, Ethan Furman <ethan@stoneleaf.us> 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. ChrisA
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Function decorator having arguments is complicated Chris Angelico <rosuav@gmail.com> - 2015-04-27 14:32 +1000
csiph-web