[Python-Dev] Re: decorators and 2.4
Phillip J. Eby
pje at telecommunity.com
Mon Jun 28 22:05:01 EDT 2004
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:
from lib1 import SomeClass
from lib2 import 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.
More information about the Python-Dev