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]: 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. 2. The decorator part can contain arbitrary expressions. This makes it impossible for most syntax colorizers to find the function name in (a). Finding the defining occurences of names is the most important thing a code navigator can do. 3. In (b) the function name is separated from the argument list, making the definition look very different from a function call. 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. 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. To see argument 5, compare these illustrations: (a) ---------- then do this | .-----. v .-----------------. | def | [decorator] | func(arg, arg): | | '-------------' | <-- first do this | print arg + arg | '-------------------------------------' (b) ----- then do this | .----------. v .-------------. | def func | [decorator] | (arg, arg): | | '-------------' | <-- first do this | print arg + arg | '--------------------------------------' (c) first do this then do this | | v | .---------------------. v | def func(arg, arg) | [decorator]: | print arg + arg | '---------------------' I claim (c) is much easier to visually understand. -- ?!ng
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