[Python-Dev] Re: decorators and 2.4

[Phillip J. Eby]

At 09:23 AM 6/26/04 -0500, Jeff Bone wrote:

>>Uh, the WHOLE POINT we want this is to have side-effects.  If it doesn't 
>>make the function act in a different way, it might as well live in the 
>>doc string or something.
>
>Declarative vs. imperative.  Design-time *definitional* modification of 
>behavior vs. runtime.  I don't really think you want side-effects in the 
>literal sense.

Actually, he very well might, and a number of other people definitely 
do.  One use case repeatedly mentioned on Python-Dev has been to register 
functions or classes with frameworks, therefore definitely involving a 
literal side-effect (i.e. modification to an unrelated data structure).

(I wonder if I should submit a patch for PEP 318 to add this to the 
motivation section, because it seems a lot of people keep repeating this 
"no side-effects metadata" misconception.)


>E.g. "classmethod" isn't a side-effect, it's a definitional thing.  If you 
>really want side-effecting operations on functions, you've already got 
>that given higher-order / first-class functions.

Please read the current "Motivation" section of PEP 318.  The point isn't 
that such operations aren't possible, it's that they're not very readable 
in standard Python syntax.

In contrast, most other languages with first-class functions allow function 
definitions to be used as *expressions*, which means that they can be 
nested within a decoration expression, giving the reader a context for 
understanding the function definition.  PEP 318 seeks to remedy this 
clarity/readability issue, by providing an alternative syntax for 
expressions that will "wrap" a function definition that follows.