[Python-Dev] def ... decorate (original) (raw)

Skip Montanaro skip at pobox.com
Fri Aug 13 17:44:17 CEST 2004

(posting to python-dev separately from c.l.py so the thread can live or die on its own in both places)

I responded on c.l.py to a couple proposals:

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

Nick>  as:
Nick>      staticmethod
Nick>      grammarrule('statement : expression')
Nick>      version("Added in 2.4")
Nick>      deprecatedmethod
Nick>      type_(None)
Nick>  def p_statement_expr(self, p):
Nick>      print p[1]

with

def p_statement_expr:
    staticmethod
    grammarrule('statement : expression')
    version("Added in 2.4")
    deprecatedmethod
    type_(None)
decorate (self, p):
    """docstring here"""
    print p[1]

It seems different enough from other solutions that I thought it worth tossing out. I didn't see it mentioned in the PythonDecorators moin page.

Read it something like "define a function named p_statement_expr using a bunch of functions to decorate the basic function".

It solves a couple problems:

  1. "def" introduces the function definition instead of an arbitrary number of @-expressions.

  2. There is no extra indentation of the main body.

  3. The name of the function is known early on.

  4. "def"/"decorate" pair up visually much the same as "try"/"except" or "if"/"then", though they don't represent alternative blocks of code to be executed.

On the minus side it introduces a vertical separation between the function name and parameter list and introduces a new keyword, "decorate".

From a parsing standpoint I think it will work. You'll see either a colon or a left paren after the function name to distinguish between the two types of function definition. I'm not sure if a token needs to be used to separate the various decorator functions or if requiring a newline and indentation is sufficient.

Skip

More information about the Python-Dev mailing list