Are decorators really that different from metaclasses...

[Paul Morrow]

....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

 

[Colin J. Williams]

...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.

 

[Larry Bates]

You are asking the same question I asked in a separate
posting to c.l.p (but apparently more clearly).

I thought about using:

class Foo:
""" This is the docstring for class Foo. """
__decorators__ = {'metaclass': 'M'}
# body of class goes here


def baz():
""" This is the docstring for function baz. """
__decorators__= {'features': ['synchronized', 'memoized'],
'docstring':'This is the docstring for function baz. '}
# body of function goes here.

This seems extendable (e.g. you can add keys to __decorators__
dictionary without disturbing existing keys) and "sort of"
parallels __dict__ which everyone understands.

Some of these discussions are so far over my head that I thought
my idea didn't somehow make any sense at all. Then I saw your post.

Thanks,
Larry Bates
Syscon, Inc.