Alternative decorator syntax decision
anthonybaxter at gmail.com
Fri Aug 20 10:35:50 CEST 2004
On Fri, 20 Aug 2004 03:37:12 -0400, Nicolas Fleury
<nid_oizo at yahoo.com_removethe_> wrote:
> - Not Pythonic. It's a line without a block (like try/finally) that
> affects a following line of code. It breaks interactive shells.
I've seen this mentioned a couple of times, but as far as I can see,
it's really not true:
>>> def noop(func):
... return func
>>> def funcattr(**kwdict):
... def _deco(func, kwdict=kwdict):
... for k,v in kwdict.items():
... return func
... return _deco
... def testfunc(whatever):
>>> print testfunc.foo
>>> print testfunc.bar
>>> print testfunc.bing
['b', 'o', 'n', 'g']
> [ snip - decorate block before def ]
> This proposal has basically the advantages of @decorators with a more
> Pythonic approach. The main drawback is that the decorate block doesn't
> contain anything like normal statements, as with @decorators.
> Implementation already exists.
Note that the implementation, as far as I know, is not yet complete - it
doesn't include the from __future__ stuff. I don't know much about that
area of the implementation, so can't offer an opinion on how hard that
The implementation also doesn't seem to have been submitted as a
patch to SF. This needs to be done.
> Proposal 2:
> def foo(a,b):
> using staticmethod
This form (decorators inside the block) has been pretty convincingly
ruled out by Guido. I think the "last man standing" is the decorator-before-def
form, I really doubt you're going to convince people that the form inside the
function is workable.
More information about the Python-list