[Python-Dev] Re: decorators and 2.4

[Jeff Bone]

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. ;-)