(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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4