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!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sat, 15 Sep 2012 07:18:18 -0700 (PDT)
In-Reply-To: <mailman.742.1347703468.27098.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=123.192.32.215; posting-account=5JdMBQoAAABHnS4mjpqEzxnmWtgiiVNw
References: <f7e2ec78-2c4a-402e-9a90-6cf0e7e55a54@c8g2000pbe.googlegroups.com> <20120914021211.GA15642@cskk.homeip.net> <k3043s$pj$1@ger.gmane.org> <mailman.722.1347657439.27098.python-list@python.org> <5053c030$0$29981$c3e8da3$5496439d@news.astraweb.com> <a6de2f24-c9af-4193-8ce3-63743fe424be@googlegroups.com> <mailman.742.1347703468.27098.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: Decorators not worth the effort
From: 88888 Dihedral <dihedral88888@googlemail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org, 88888 Dihedral <dihedral88888@googlemail.com>
Precedence: list
Message-ID: <mailman.751.1347718701.27098.python-list@python.org>
Lines: 351
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:29230

David Hutto=E6=96=BC 2012=E5=B9=B49=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=
=E5=85=ADUTC+8=E4=B8=8B=E5=8D=886=E6=99=8204=E5=88=8628=E7=A7=92=E5=AF=AB=
=E9=81=93=EF=BC=9A
> On Sat, Sep 15, 2012 at 5:45 AM, 88888 Dihedral
>=20
> <dihedral88888@googlemail.com> wrote:
>=20
> > Steven D'Aprano=E6=96=BC 2012=E5=B9=B49=E6=9C=8815=E6=97=A5=E6=98=9F=E6=
=9C=9F=E5=85=ADUTC+8=E4=B8=8A=E5=8D=887=E6=99=8239=E5=88=8628=E7=A7=92=E5=
=AF=AB=E9=81=93=EF=BC=9A
>=20
> >> On Fri, 14 Sep 2012 15:16:47 -0600, Ian Kelly wrote:
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> > If only there were a conceptually simpler way to do this.  Actually,
>=20
> >>
>=20
> >> > there is.  I give you: muman than humanetadecorators!
>=20
> >>
>=20
> >> [code snipped but shown below]
>=20
> >>
>=20
> >> > Which I think is certainly easier to understand than the nested
>=20
> >>
>=20
> >> > functions approach.
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> Maybe for you, but to me it is a big ball of mud. I have no idea how t=
his
>=20
> >>
>=20
> >> is supposed to work! At a quick glance, I would have sworn that it
>=20
> >>
>=20
> >> *can't* work, since simple_decorator needs to see multiple arguments b=
ut
>=20
> >>
>=20
> >> only receives one, the function to be decorated. And yet it does work:
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> py> from functools import partial
>=20
> >>
>=20
> >> py> def make_wrapper(wrapper):
>=20
> >>
>=20
> >> ...     return lambda wrapped: partial(wrapper, wrapped)
>=20
> >>
>=20
> >> ...
>=20
> >>
>=20
> >> py> @make_wrapper
>=20
> >>
>=20
> >> ... def simple_decorator(func, *args, **kwargs):
>=20
> >>
>=20
> >> ...     print "Entering decorated function"
>=20
> >>
>=20
> >> ...     result =3D func(*args, **kwargs)
>=20
> >>
>=20
> >> ...     print "Exiting decorated function"
>=20
> >>
>=20
> >> ...     return result
>=20
> >>
>=20
> >> ...
>=20
> >>
>=20
> >> py> @simple_decorator
>=20
> >>
>=20
> >> ... def my_function(a, b, c):
>=20
> >>
>=20
> >> ...     """Doc string"""
>=20
> >>
>=20
> >> ...     return a+b+c
>=20
> >>
>=20
> >> ...
>=20
> >>
>=20
> >> py> my_function(1, 2, 3)
>=20
> >>
>=20
> >> Entering decorated function
>=20
> >>
>=20
> >> Exiting decorated function
>=20
> >>
>=20
> >> 6
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> So to me, this is far more magical than nested functions. If I saw thi=
s
>=20
> >>
>=20
> >> in t requires me to hunt through your library for the "simple function
>=20
> >>
>=20
> >> buried in a utility module somewhere" (your words), instead of seeing
>=20
> >>
>=20
> >> everything needed in a single decorator factory function. It requires
>=20
> >>
>=20
> >> that I understand how partial works, which in my opinion is quite tric=
ky.
>=20
> >>
>=20
> >> (I never remember how it works or which arguments get curried.)
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> And the end result is that the decorated function is less debugging-
>=20
> >>
>=20
> >> friendly than I demand: it is an anonymous partial object instead of a
>=20
> >>
>=20
> >> named function, and the doc string is lost. And it is far from clear t=
o
>=20
> >>
>=20
> >> me how to modify your recipe to use functools.wraps in order to keep t=
he
>=20
> >>
>=20
> >> name and docstring, or even whether I *can* use functools.wraps.
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> I dare say I could answer all those questions with some experimentatio=
n
>=20
> >>
>=20
> >> and research. But I don't think that your "metadecorator" using partia=
l
>=20
> >>
>=20
> >> is *inherently* more understandable than the standard decorator approa=
ch:
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> def simple_decorator2(func):
>=20
> >>
>=20
> >>     @functools.wraps(func)
>=20
> >>
>=20
> >>     def inner(*args, **kwargs):
>=20
> >>
>=20
> >>         print "Entering decorated function"
>=20
> >>
>=20
> >>         result =3D func(*args, **kwargs)
>=20
> >>
>=20
> >>         print "Exiting decorated function"
>=20
> >>
>=20
> >>         return result
>=20
> >>
>=20
> >>     return inner
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> This is no more complex than yours, and it keeps the function name and
>=20
> >>
>=20
> >> docstring.
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> > Parameterized decorators are not much more
>=20
> >>
>=20
> >> > difficult this way.  This function:
>=20
> >>
>=20
> >> [snip code]
>=20
> >>
>=20
> >> > And now we have a fancy parameterized decorator that again requires =
no
>=20
> >>
>=20
> >> > thinking about nested functions at all.
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> Again, at the cost of throwing away the function name and docstring.
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> I realise that a lot of this boils down to personal preference, but I
>=20
> >>
>=20
> >> just don't think that nested functions are necessarily that hard to
>=20
> >>
>=20
> >> grasp, so I prefer to see as much of the decorator logic to be in one
>=20
> >>
>=20
> >> place (a nested decorator function) rather than scattered across two
>=20
> >>
>=20
> >> separate decorators plus partial.
>=20
>=20
>=20
> Like chi fu, allow decorators to evolve upon themselves. Like simple
>=20
> moves flow through water and allow memorization of activity through
>=20
> evidence of existence.
>=20
>=20
>=20
>=20
>=20
> --=20
>=20
> Best Regards,


The concept of decorators is just a mapping from a function to another
function with the same name in python.


It should be easy to be grapsed for those studied real analysis and=20
functional analysis.
 =20