Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <k3043s$pj$1@ger.gmane.org>
References: <f7e2ec78-2c4a-402e-9a90-6cf0e7e55a54@c8g2000pbe.googlegroups.com> <20120914021211.GA15642@cskk.homeip.net> <k3043s$pj$1@ger.gmane.org>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Fri, 14 Sep 2012 15:16:47 -0600
Subject: Re: Decorators not worth the effort
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.722.1347657439.27098.python-list@python.org>
Lines: 96
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:29190

On Fri, Sep 14, 2012 at 2:29 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> 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?

If only there were a conceptually simpler way to do this.  Actually,
there is.  I give you: metadecorators!

First, the simple, non-parameterized case:

from functools import partial

def make_wrapper(wrapper):
    return lambda wrapped: partial(wrapper, wrapped)

With that simple function buried in a utility module somewhere, we can do:

@make_wrapper
def simple_decorator(func, *args, **kwargs):
    do_stuff()
    result = func(*args, **kwargs)
    do_more_stuff()
    return result

Which I think is certainly easier to understand than the nested
functions approach.  Parameterized decorators are not much more
difficult this way.  This function:

def make_parameterized_wrapper(wrapper):
    return lambda *params: lambda wrapped: partial(wrapper, wrapped, params)

enables us to write:

@make_parameterized_wrapper
def complex_decorator(func, (param1, param2, param3), *args, **kwargs):
    do_stuff(param1, param2)
    result = func(*args, **kwargs)
    do_more_stuff(param2, param3)
    return result

And now we have a fancy parameterized decorator that again requires no
thinking about nested functions at all.  Sadly, that last bit of
syntax will only work in Python 2; tuple parameter unpacking was
removed in Python 3.  It's not a complicated upgrade path, however:

@make_parameterized_wrapper
def complex_decorator(func, params, *args, **kwargs):
    (param1, param2, param3) = params
    do_stuff(param1, param2)
    result = func(*args, **kwargs)
    do_more_stuff(param2, param3)
    return result

Cheers,
Ian