PEP 318 decorators are not Decorators

[Arien Malec]

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

Arien

[Arthur]

On Sun, 15 Aug 2004 18:29:52 GMT, Arien Malec
<ar*********@ya hoo.com.REMOVE> wrote:

Skip Montanaro <sk**@pobox.com > wrote in
news:ma******* *************** *************** *@python.org:

Arien> 3) Won't most programmers think GoF decorators before
Arien> compiler syntax tree decorators?

Skip> Not if they are unfamiliar with the GoF patterns (myself
included).

Arien> Google: [~62,000 : ~130 mentions of each sort of decorator]

...

BFD.... The thing is, just because in a verbal Rohrschach
test you think "GoF" when someone says "decorator" doesn't mean
everybody else will (or should).

Correct. I would think simply that "decorate" would be descriptive in
its own right.

As obscure as the GOF reference might be to some, the alternative
references justifying the naming seem to be off the map in terms of
obscurity. So let's assume a blank slate. And all we want is the
word to be descriptive.

And it seems to me the naming is in fact descriptive - but of the
syntax, not the functionality.

Which is OK, I guess, if we accept it as that.

As there are already a number of compromises being made in the
addition of this to the language, I just think of this as one more.

Clearly, Python can choose any name for the auto-function-transformation
syntax in question, but it's rather willfully confusing to choose a name
that's heavily identified with a profoundly different semantics that's
superficiall y similar in intent.

Again, a little different if we think of it as describing the syntax,
not the functionality. Yes the ambiguity, I agree, is bad. And yes,
I agree, willful, to an extent. Or at least willful to the extent that
there is little interest in truly justifying the choice of
terminology, and specifung whether we are referencing the syntax or
the functionality in the choice of the terminology.

This ambiguity is to the essence of decorators, maybe both as syntax
and as functionailty. But it is not the first time I have issues with
python-dev folks using ambiguity as gloss.

Art

[Arien Malec]

"Colin J. Williams" <cj*@sympatico. ca> wrote in
news:Ns******** **********@news 20.bellglobal.c om:

Arien Malec wrote:

Clearly, Python can choose any name for the
auto-function-transformation syntax in question, but it's rather
willfully confusing to choose a name that's heavily identified with a
profoundly different semantics that's superficially similar in
intent.

This is especially confusing as, in everyday english usage, to
decorate is not the same as to transform.

Perhaps "transform" could be consdered as an alternative.

That would be my leaning, as well. Ideally, the name would make it clear
that the application order of the transformations is significant....

Arien