Alternative decorator syntax decision

[Anthony Baxter]

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():
...             setattr(func,k,v)
...         return func
...     return _deco
... 
>>> @noop
... @funcattr(foo=1,bar='bozo',bing=['b','o','n','g'])
... def testfunc(whatever):
...     pass
... 
>>> print testfunc.foo
1
>>> print testfunc.bar
bozo
>>> 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 
is.

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.