Ka-Ping Yee wrote: > This discussion is turning in a direction that alarms me. > > Putting the [decorator] on a separate line before the function > changes the stakes entirely. It sets aside real functional issues > in favour of aesthetics. Being enamoured with the way this syntax > *looks* does not justify functionally *breaking* other things in > the implementation to achieve it. > > Consider the arguments in favour: > > 1. Decorators appear first. > 2. Function signature and body remain an intact unit. > 3. Decorators can be placed close to the function name. > > These are all aesthetic arguments: they boil down to "the appearance > is more logical". Similar arguments have been made about the other > proposals. > > Consider the arguments against: > > 1. Previously valid code has new semantics. > 2. Parse tree doesn't reflect semantics. > 3. Inconsistent interactive and non-interactive behaviour. [*] > 4. Decorators can be arbitrarily far away from the function name. Agreed, although I won't use such alarmist phrases. ;) Notice that the form: decorate: dec1 dec2 def foo(arg1, arg2, ...): pass gives all of the benefits you mentioned without incurring any of the "arguments against", except possibly #4. The PEP itself gives the "arguments against" this form as: 1. "The function definition is not nested within the using: block making it impossible to tell which objects following the block will be decorated" Somewhat of an oblique argument, to which the simple answer is: there must be a def right after it, in exactly the same manner that a try: must be followed by an except: or finally: 2. An argument which only applies if foo is inside the decorate block. I don't advocate that. 3. Another. 4. "Finally, it would require the introduction of a new keyword." Yup. Not a bad thing for such a powerful tool, IMO. Robert Brewer MIS Amor Ministries fumanchu at amor.org
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