Are decorators really that different from metaclasses...

[Colin J. Williams]

Paul Morrow wrote:

> ...that they warrant an entirely new syntax?  It seems that they are 
> very similar in a very significant way --- they alter the default 
> behavior of something.  IMO, it's not a stretch to say that they 
> 'parallel' metaclasses; that they are to functions/methods what 
> metaclasses are to classes.  So why don't they share a similar syntax?
> 
>    class Foo:
>       """ This is the docstring for class Foo. """
>       __metaclass__ = M
>       # body of class goes here
> 
> 
>    def baz():
>       """ This is the docstring for function baz. """
>       __features__ = synchronized, memoized
>       # body of function goes here.
> 
> 
> I personally find the above baz function aesthetically appealing.  Does 
> anyone else feel this way?  For contrast, below is the same function 
> written in the proposed A1 and J2 [*] syntaxes (respectively).
> 
> 
>    @synchronized
>    @memoized
>    @doc(""" This is the docstring for function baz. """)
>    def baz():
>       # body of function goes here.
> 
> 
>    decorate:
>       """ This is the docstring for function baz. """
>       synchronized
>       memoized
>    def baz():
>       # body of function goes here.
> 
> 
> * if J2 is accepted, the name 'decorate' may be replaced with some other 
> keyword, but I believe that the structure of the syntax would stay the 
> same.
> 
> Paul
> 
Robert Brewer provided an excellent review of the options now on the 
table, but he didn't explore the question of whether there is an 
existing structure on which these new operations, which are mainly 
transformations, can be based.
           http://www.aminus.org/rbre/python/pydec.html

There seems to be an artificial deadline which is motivating the push to 
implement something, even though the effect can already be achieved, in 
a less desirable way, by placing the transformer aka decorator after the 
function body.

I like the general thrust of this proposal - let's use existing 
structures if this is possible.  The idea of putting the modifier 
__features__ after the thing named and given a signature also makes sense.

Colin W.