Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Decorators not worth the effort
Date: Fri, 14 Sep 2012 16:33:01 -0400
References: <f7e2ec78-2c4a-402e-9a90-6cf0e7e55a54@c8g2000pbe.googlegroups.com> <20120914021211.GA15642@cskk.homeip.net> <k3043s$pj$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0
In-Reply-To: <k3043s$pj$1@ger.gmane.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.720.1347655802.27098.python-list@python.org>
Lines: 67
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:29188

On 9/14/2012 4:29 PM, Terry Reedy wrote:
> On 9/13/2012 10:12 PM, Cameron Simpson wrote:
>> On 13Sep2012 18:58, alex23 <wuwei23@gmail.com> wrote:
>> | On Sep 14, 3:54 am, Jean-Michel Pichavant <jeanmic...@sequans.com>
>> | wrote:
>> | > I don't like decorators, I think they're not worth the mental effort.
>> |
>> | Because passing a function to a function is a huge cognitive burden?
>
> For parameterized decorators, there is extra cognitive burden. See below.
>
>
>> It is for me when I'm _writing_ the decorator:-) But if I get it right
>> and name it well I find it dramaticly _decreases_ the cognitive burden
>> of the code using the decorator...
>
> For a simple, unparameterized wrapper, the difficulty is entirely in the
> wrapper maker. It must define the final wrapper as a nested function and
> return it*. It is irrelevant whether the wrapper maker is used with
> pre-def decorator syntax or with an explicit post-def call.
>
> *I am here ignoring the option of a class with __call__ method.
>
> For a parameterized wrapper, using decorator syntax requires passing the
> parameter(s) first and the function to be wrapped later. This requires
> currying the wrapper maker with double nesting. The nesting order may
> seem inside-out to some. For most people, this is extra work compared to
> writing a wrapper that accepts the function and parameters together and
> only has a single level of nesting.
>
> In other words
>
> def make_wrapper(func, param):
>      def wrapper(*args, **kwds):
>          for i in range(param):
>              func(*args, **kwds)
>      return wrapper
>
> def f(x): print(x)
> f = make_wrapper(f, 2)
> f('simple')
>
> # is simpler, at least for some people, than the following
> # which does essentially the same thing.
>
> def make_outer(param):
>      def make_inner(func):
>          def wrapper(*args, **kwds):
>              for i in range(param):
>                  func(*args, **kwds)
>          return wrapper
>      return make_inner
>
> @make_outer(2)
> def f(x): print(x)
> f('complex')
>
> Is the gain of not repeating the wrapped function name twice in the
> post-def wrapping call, and the gain of knowing the function will be
> wrapped before reading the def, worth the pain of currying the wrapper
> maker?
>


-- 
Terry Jan Reedy