[Python-Dev] Another decorator syntax idea (original) (raw)
barnesc at engr.orst.edu barnesc at engr.orst.edu
Sat Aug 7 02:38:27 CEST 2004
- Previous message: [Python-Dev] Re: [SPAM: 3.611] IPython, @, and option E from the wiki
- Next message: [Python-Dev] pre-PEP: Complete, Structured Regular Expression Group Matching
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Another decorator syntax idea
Using Guido's example:
@ Symbols
class C(object):
@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 NotYetImplementeddecorate keyword
class C(object):
def longMethodNameForEffect(longArgumentOne=None,
longArgumentTwo=42):
decorate:
staticmethod
funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]", \
status="experimental", author="BDFL")]
"""This method blah, blah.
It supports the following arguments:
- longArgumentOne -- a string giving ...
- longArgumentTwo -- a number giving ...
blah, blah.
"""
raise NotYetImplementedPros:
- Doesn't hide the function name behind @ garbage.
- 'decorate' is easier to look at than '@'.
- 'decorate' is more meaningful to most readers than '@'.
- Block structure isolates decorators from surrounding code, making them more readable.
- Indentation rules are consistent with the rest of Python.
Cons:
Not pear shaped.
Connelly
- Previous message: [Python-Dev] Re: [SPAM: 3.611] IPython, @, and option E from the wiki
- Next message: [Python-Dev] pre-PEP: Complete, Structured Regular Expression Group Matching
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]