Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Sun, 26 Apr 2015 21:45:00 -0700
From: Ethan Furman <ethan@stoneleaf.us>
To: python-list@python.org
Subject: Re: Function decorator having arguments is complicated
Mail-Followup-To: python-list@python.org
References: <CAFTm5Ru5NbFOtLPoVSPujeakrGawdHXjNkWJOVs1XrvBNnOUOQ@mail.gmail.com> <20150427042426.GD32422@stoneleaf.us> <CAPTjJmpYOoTLCL6hk2MDk5_V2ffmA-wON2rbnG_cE6oDjg9YoQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPTjJmpYOoTLCL6hk2MDk5_V2ffmA-wON2rbnG_cE6oDjg9YoQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.36.1430109903.3680.python-list@python.org>
Lines: 42
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:89442

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~