On Jun 28, 2004, at 3:11 PM, Phillip J. Eby wrote: > So, to talk about applying restrictions to what behavior is allowed > for decorators, is to completely miss the point of PEP 318. Please > re-read PEP 318's "Motivation" section. Phil, with all due respect, there's no need to get peevish. I've read PEP 318 several times, and I think you're missing my point *about the PEP.* You'll note that I'm not disagreeing with the desirability of decorators nor any of the use cases in the PEP nor any given proposed syntax. I'm concerned that treating this as simple syntactic sugar w/o a bit more precision about impact on evaluation and on scope might actually impair the ability to use decorators for (at least some of) their intended purposes. The PEP only implies semantics (by saying "it's just syntactic shorthand for things like...") --- and that implied semantics is in fact inconsistent with at least one of the implied desiderata. Note too that an explicit design goal of the PEP is: * not make future extensions more difficult If you allow conditional evaluation or parameterization of decorators w/o some consideration about their impact on static type analysis --- as in the nightmare scenario I offered previously --- AND if you believe that adding some optional static typing and type analysis to Python in the future is at least possibly desirable, then it leads one to consider whether additional constraints *might* be in order. E.g. if evaluation of decorators proceeds "at runtime" then we can forget all ideas of using them for any sort of static code analysis which, if you noticed, *is* one of the examples from the PEP. (That would be the "Examples" section, ahem. ;-) jb Footnote, aside, more of an anecdotal cautionary tale than anything else: Today the following happens: > >>> def bar(): > ... x = 3 > ... foo() > ... > >>> def foo(): > ... print x > ... > >>> bar() > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "<stdin>", line 3, in bar > File "<stdin>", line 2, in foo > NameError: global name 'x' is not defined > >>> This is as it should be. Decorators shouldn't have an impact on variables that occur free in decorated bodies. This is an example of the lack of clarity in the spec; you can argue that it's implicit that this kind of behavior should be preserved, but IMHO that's more a function of some implied understanding of the implementation than it is any specification of something that the language should or should not do. (And such problems lead early Lisp to have effed up scoping rules for so long that old Lisp hands can't even agree on whether it was a feature or a bug. ;-)
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