Revised PEP 318 - Function/Method Decorator Syntax

[Bernhard Herzog]

bokr at oz.net (Bengt Richter) writes:

> On 10 Jun 2003 12:25:13 GMT, Kevin Smith <Kevin.Smith at sas.com> wrote:
> 
> >        def foo(self) {'pre': synchronized(lock), 'classmethod': True}:
> >            perform method operation
> >
> >    These three forms use syntax that just seems arbitrary and which 
> >    does not help the user to comprehend the meaning of it.  In 
> >    addition, since the order in which the decorators are applied 
> >    may matter, the third, dictionary-style, syntax must be 
> >    eliminated.
> I disagree with that "must" ;-) Better to say ordering must be
> specified by other means. E.g., trivially, you could add
> 'ordering':('pre','classmethod') to the above dict.

The strings used in the dictionary seem to have special meaning,
especially the "classmethod" in the example above. Who defines that
meaning and how do add new strings with new meanings?

I think the dict like syntax if used for anything at all should be used
for function attributes and not decorators so that instead of 

def foo(self):
    pass

foo.my_attr = "bar"

I could write

def foo(self) {"my_attr": "bar"}:
    pass


But then again with decorators I might just as well write

def foo(self) as attributed(my_attr = "bar"):
    pass

with attributed defined as e.g.

def attributed(**kw):
    def add_attrs(f):
        for key, value in kw.items():
            setattr(f, key, value)
    return add_attrs


> Using a class with a general __init__(*args,**kw) parameter list will
> permit defining builtins for standard decorations and creating
> customized/derived versions as well. The list/tuple syntax
> functionality could easily be implemeted with a class by putting the
> elements in the call to the constructor, e.g.,
> 
>          'def' NAME '(' PARAMETERS ')' ['as' DECORATORS_CLASS ['(' DECORATORS ')']] ':'
> 
> where standard DECORATORS could already be built in to a standard
> DECORATORS_CLASS, or a parenthesized sequence could follow, but also
> allow keyword items. You could specify DECORATORS exactly as you
> propose, but now the door would be open to future ideas of decoration
> specification.

There's no need to add special syntax for this class based approach. The
'as' version which allows arbitrary expressions supports this already.


> >        def foo(self) as synchronized(lock), classmethod:
> >            perform method operation
> 
>          def foo(self) as DECORATORS(synchronized(lock), classmethod):
>              perform method operation
> 
> where DECORATORS would be a builtin standard decoration control class
> for your kind of decoration sequences.

You can easily implement DECORATORS yourself with the 'as' version as is
if you want.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                           http://www.mapit.de/