> The most obvious issues I see with this is are that: > - grepping for "def func" won't show any sign that its decorated, and Seems rather minor -- there's only so much you can cram on a single line. > - it looks like normal syntax, so it looks like expressions should > work, e.g. > > [decorator1] + [decorator2] > def func(arg, arg): > > or even: > > get_std_decorators() # Returns a list > def func(arg, arg): > > I'm pretty sure this isn't the intention, though. I can imagine > some posts to comp.lang.python asking how to do the above... The same syntactic restrictions apply to docstrings (you can't have an expression of type string in the docstring position, it *has* to be a literal). Nobody's confused by that one. > Neither of these are fatal flaws, but I think I still prefer: > > def func(args) [decorator]: Which hides 'classmethod' behind the more voluminous stuff, and that's my main gripe. My main reasoning is as follows: 1) If we do decorators at all, decorators should be allowed to be arbitrary expressions. 2) Since we allow arbitrary expressions, decorators provide a much better way to set function attributes than the current way. 3) This will be attractive (better than putting special mark-up in docstrings), so there will be lots of voluminous decorators. 4) Then the "important" decorators like classmethod will be hidden at the end of the list of decorators. The [...] prefix proposal addresses this by putting the end of the decorator list closest to the def keyword. This doesn't look so bad: [funcattr(spark="<spark syntax here>", deprecated=True, overrides=True), classmethod] def foo(cls, arg1, arg2): pass --Guido van Rossum (home page: http://www.python.org/~guido/)
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