[Python-Dev] Re: decorators and 2.4

[Phillip J. Eby]

At 04:29 PM 6/28/04 -0500, Jeff Bone wrote:
>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.

No, it doesn't.  You can already make weird decorators that disassemble the 
bytecode of the function and create a new function object, for 
example.  PEP 318 does nothing to change that fact.  Thus, attempting to 
define restrictions for them is moot, as far as anybody attempting to 
create program analysis tools -- they already have to deal with this 
dynamism today, and restricting PEP 318 simply won't help.


>   E.g. if evaluation of decorators proceeds "at runtime" then we can 
> forget all ideas of

For all practical purposes, Python doesn't have any time *other* than 
runtime.  Any analysis tool that doesn't recognize this is going to have a 
hard time making sense out of Python code.  As a simple example:

     try:
         from lib1 import SomeClass
     except ImportError:
         from lib2 import SomeClass

     class MyClass(SomeClass):
         """My stuff here"""

So, what class does 'MyClass' inherit from, here?  Note that this is 
perfectly legal Python, and I've certainly written the equivalent of it 
more than once or twice.  So if this be the stuff of nightmares, please 
don't try to wake me up.  :)


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

To which example are you referring?  Type constraints?  That's not static 
code analysis, that's code generation.  Interfaces?  That's 
registration.  Neither has anything to do with static code analysis, AFAICT.


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

If that's true, then the Python language reference is unclear because it 
doesn't say that you mustn't use higher-order functions to change the 
behavior of other functions.