At 07:52 PM 8/13/04 +0200, Werner Schiendl wrote: >was the following suggested already? (don't think so): > > def p_statement_expr(self, p): > staticmethod > grammarrule('statement : expression') > version("Added in 2.4") > deprecatedmethod > type_(None) > body: > """docstring here""" > print p[1] hmmmm.... that's really not much different from: def p_statement_expr(self, p) [ staticmethod, grammarrule('statement : expression'), version("Added in 2.4"), returns(None) ]: """Docstring""" body is it? But then, how about *this*: def p_statement_expr(self, p) @staticmethod @grammarrule('statement : expression') @version("Added in 2.4") @returns(None) as: """Docstring""" body The decorators are much more visible with the @ signs. Also, we could possibly allow the docstring to appear in the def statement, rather than in the body, e.g.: def p_statement_expr(self, p) @staticmethod @grammarrule('statement : expression') @version("Added in 2.4") @returns(None) """Docstring""" as: body Some advantages: * Tools that just only look at 'def funcname(signature)' still work * Tools that only look for '@something' at the start of the line will work (e.g. I believe this means IPython will still work, dunno about Leo) * Decorators are much more visible than in the list-after-def forms, but are still visibly part of the function definition * You know the name/signature of the thing being defined before wading through decorators Disadvantages: * line continuation isn't standard; there ought to be brackets or parentheses, otherwise tokenizer will say there's an INDENT, and it's not standard to have an INDENT without a colon. * How would we define the syntax? Should it be something like this: classdef: 'class' NAME ['(' testlist ')'] [decorations] ':' suite funcdef: 'def' NAME parameters [decorations] ':' suite decorations: NEWLINE INDENT decorator* [docstring NEWLINE] DEDENT 'as' decorator: '@' test NEWLINE In other words, should indent and one-decorator-per-line be enforced? * Guido has argued that list-after-def is bad in the case of a long argument list, because of poor visibility. Does this approach fix that?
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