[Python-Dev] Re: decorators and 2.4
Phillip J. Eby
pje at telecommunity.com
Sat Jun 26 11:27:25 EDT 2004
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
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.
More information about the Python-Dev