Ka-Ping Yee: > Three different positions for decorators have been suggested: > (a) def [decorator] func(arg, arg): > (b) def func [decorator] (arg, arg): > (c) def func(arg, arg) [decorator]: You forgot before and after using: classmethod def func(arg1, arg2): pass def func(arg1, arg2): .classmethod pass There is also a possibility of two separate places, depending on whether the original object is (1) returned, possibly with extra attributes, or (2) replaced with a new entry point (which might or might not forward to the original, change the signature entirely, do something completely different). using: classmethod def func(arg1, arg2): .annotation pass I would personally prefer to see both types before the def, but separated from each other. I do understand that this gets bulky; it scales up better than it scales down. note: .name1 = value .name2 = val2 using: classmethod def func(arg1, arg2): pass >There are several strong arguments to choose (c). > 1. The decorator part is optional. Optional things usually come > at the end and shouldn't interrupt non-optional things. Agreed, but taking it out of the (current) funcdef header clause entirely also meets this goal. The question is whether it would still bind tightly *enough* to the funcdef. > 4. When you're reading the body of the function, you will refer > to the arguments frequently and the decorators not at all. > So the arguments should come first, in the usual position. classmethod does make a difference, because it changes the signature. One of Guido's questions is whether there will ever be a long chain of *tranforming* decorators. We have seen examples of long chains of decorators, but I don't think anyone has a concrete use case with more than two *transforming* decorators. If chains really stay short, then def classmethod func(arg1, arg2): pass looks OK. (Except that new users will assume classmethod is a keyword, and try to look it up -- which does not work for user-created decorators.) > 5. The decorators act on the function after the entire function > definition has been evaluated. It makes sense to arrange the > function as a visual unit so you can see what is being created > and manipulated. You can already put them after the full definition; the reason for this syntax is to move them up so that people can keep them in mind while reading the definition. -jJ
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