A decorator syntax not yet mentioned (I think!)

[Michael Sparks]

Peter Hansen wrote:
> class Klass:
>      # init set
> 
>      decorate:
>          staticmethod
>      def meth0(x):
>          return x

If it counts for anything, +1.

This strikes me personally as a very nice alternative to the
current suggestion.

The idea of paired keywords is sufficiently common in python
to strike me as another positive element.

Using the examples on http://www.python.org/moin/PythonDecorators

You gain something like:
class C(object):

    decorate:
        staticmethod,
        funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
                  status="experimental", author="BDFL")
    def longMethodNameForEffect(longArgumentOne=None,
                                longArgumentTwo=42):
        """This method blah, blah.

        It supports the following arguments:
        - longArgumentOne -- a string giving ...
        - longArgumentTwo -- a number giving ...

        blah, blah.

        """
        raise NotYetImplemented

And:

decorate:
   accepts(int,int)
   returns(float)
def bar(low,high):
  pass

Which strikes me as pretty good - the fact the method is a static method
is still in your face. The decorate keyword suggests some voodoo
happening you might want to be wary of.

The only downside I can see is that it might not be 100% obvious that it
relates to the following function to newcomers to python.

The other really nice thing about it is it directly suggests that the
following functions will be applied to the function.

Taking a subset of a simple PLY type grammar from, you gain something
like:

class Calc(Parser):
    decorate:
       tokenrule(r'\d+')
    def t_NUMBER(self, t):
        t.value = int(t.value)
        return t

    decorate:
       tokenrule(r'\n+')
    def t_newline(self, t):
        t.lineno += t.value.count("\n")

    decorate:
       grammarrule('statement : NAME EQUALS expression')
       versioninfo("Added in 2.2")
       typeinfo(int)
    def p_statement_assign(self, p):
        names[p[1]] = p[3]

    decorate:
       grammarrule('statement : expression')
       versioninfo("Added in 2.4")
       deprecated
       typeinfo(None)
    def p_statement_expr(self, p):
        print p[1]

    decorate:
       grammarrule("""
        expression : expression PLUS expression
                  | expression MINUS expression
                  | expression TIMES expression
                  | expression DIVIDE expression
                  | expression EXP expression
        """)
       versioninfo("Added in 2.4")
       typeinfo(int)
    def p_expression_binop(self, p):
        p[0] = func[p[2]](p[1],p[3])

    decorate:
       grammarrule('expression : MINUS expression %prec UMINUS')
       versioninfo("Added in 1.5")
       typeinfo(int)
    def p_expression_uminus(self, p):
        p[0] = -p[2]

    decorate:
       grammarrule('expression : LPAREN expression RPAREN')
       versioninfo("Added in 1.1")
       typeinfo(int)
    def p_expression_group(self, p):
        p[0] = p[2]

In a syntax highlighted editor that also looks *alot* cleaner than
beforehand. IMO, it also looks slightly cleaner than the @version - for
one very, very simple reason - if you have a very big decorator block,
for whatever reason, the "def" stands out clearly so you can skim where
the function starts - even without syntax highlighting.

My initial reaction to @decorators was "ugh!". However I was coming to
accept it as inevitable after reading the various arguments for/against
various syntaxes. *This* syntax strikes me personally as having
distinct advantages - largely for clarity of code, and solves the 
"where *DOES* the function start?" question with large decorator
blocks.

My tuppenceworth... (I really like this version)


Michael.
-- 
Michael.Sparks at rd.bbc.co.uk    
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.