Many people wrote:
> Lots of options
I haven't seen this mentioned, so I'm going to throw in my suggestion.
The following makes sense to me, uses previously invalid syntax, and
uses the '.' punctuation in a way similar to existing/proposed usage:
def longMethodNameForEffect(longArgumentOne=None,
longArgumentTwo=42):
.staticmethod
.funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
status="experimental", author="BDFL")
"""
asdfasdf
"""
raise NotYetImplemented
If we want to allow one-liner decorators (questionable to me):
def myMethod(self): .staticmethod
raise NotYetImplemented
Advantages/disadvantages of positioning at start of block:
+ Unambiguous "target" for decorators, matches Python's precedents for
indentation and modify-what-came-before
+ Decorators won't get lost in long argument lists (they are indented
differently in Guido's preferred formatting, and are separated by the
smiley in the all-args-on-individual-lines formatting)
+ Separate from def syntax (to keep def the same avoiding breakage)
0 Perhaps decorators should be allowed before or after the docstring. If
you have to choose, I'd choose making it before the docstring.
+ No extra cut-and-paste issues, no extra indentation level.
+ No smileys. (Does that get a :) or a ]: ?)
Advantages/disadvantages of .decorators:
+ Will not be silently ignored (doesn't use currently legal syntax)
+ Simple for simple decorators, supports complex decorators as cleanly
as possible
+ Less ugly (YMMV). Doesn't feel like executable line noise (to 1 out of
1 pythonistas polled...)
+ No new punctuation or keywords (avoids breaking Leo/IPython/existing code)
+ Really nice syntax for assigning attributes, if desired (Not sure I
like this overloading, but it /looks/ good)
def func():
.author = "Kevin Butler"
pass
+/0 Syntax obvious visually (Someone will complain that the leading
period gets lost - that person should switch to a fixed-width font, as
used when coding. <.5 wink>) Easy to highlight.
0 Although it is a punctuation-based syntax, it is compatible with
existing/proposed '.' usage ('.' can mean subordination to a containing
construct like 'with', and passing the implicit "func" argument is
analogous to passing "self")
0 Compatible with some future "with ...:" syntax, as decorators must
immediately follow a 'def ...:' (or possibly a 'class ...:'), so if
there is a 'with ...:' what follows cannot be a decorator.
- Minor extension to use of '.'
- Some people may have too much dust on their monitors
Misc items from the PEP applied to .decorators:
+ One decorator per line
+ Could use ".doc()" or ".doc = " as a docstring alternative
?+ Compile time (? as much as the @ syntax is?)
+ Works in interactive mode
Public or private feedback appreciated, I will summarize private
feedback to the list.
kb
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