PEP 318 decorators are not Decorators

[Arthur]

On Fri, 13 Aug 2004 02:56:34 GMT, Arien Malec
<arien_malec at yahoo.com.REMOVE> wrote:

>I've been following the decorator debate with some interest, and it's taken 
>me a reasonably long time to understand what is meant by a decorator. One 
>of the issues is that the Decorator pattern is more like a Unix pipe than 
>it is what PEP 318 calls a decorator. The classic decorator is run-time, 
>rather than define time, and is non-destructive to the base function. The 
>PEP 318 decorator is define time and is a destructive change to the base 
>function. For instance, the GoF book makes it clear that decorators may be 
>added or removed without affecting the underlying class.

I had first thought that the word used to describe the mechansim was
unimportant. "decorator" would come to mean, for Python, what Python
defined it to mean. 

But have concluded otherwise.  In fact using the word "decorator"
justifies the syntax, but - as you say - does not describe the impact
of that syntax in any reasonable way.

Its a bit of a con, I now think.

>
>I personally think it's confusing to reuse the "Decorator" name for 
>something that is not a classic decorator. I also agree with the many 
>comments that the proposed syntax does not make it clear that what is going 
>on is a destuctive transformation of the defined function.

Apparently in the world of declarative programming it is kosher to
make @something  mean a destructive transformation of a function
defined in its vicinity. When programming in Python. of course. And
without providing a cognative hint, or without the need to justify
itself by reference  to any other notation that ever  was. 

That precedent, of course, opens up a world of new possibilities.

Unfortunately.

Art
>
>Arien