def ... decorate

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


>>>>> "Nick" == Nick Craig-Wood <nick at craig-wood.com> writes:

    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]

How about

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

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-list mailing list