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]

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

 

[Daniel Dittmar]

decorator. One of the issues is that the Decorator pattern is more

The term decorator as used in the current discussion comes from compiler
writing. You have a syntax 'tree' which gets 'decorated' with additional
attributes.

Daniel

 

[Arien Malec]

The term decorator as used in the current discussion comes from compiler
writing. You have a syntax 'tree' which gets 'decorated' with additional
attributes.

1) That's not mentioned in PEP 318
2) That's in disagreement with
http://www.python.org/moin/PythonDecorators
3) Won't most programmers think GoF decorators before compiler syntax tree
decorators?

Arien

 

[Grant Edwards]

1) That's not mentioned in PEP 318
2) That's in disagreement with http://www.python.org/moin/PythonDecorators
3) Won't most programmers think GoF decorators before compiler syntax tree
decorators?

Thank you! I spent a while reading up on "decorators" the
other day and was completely baffled. I couldn't see that the
stuff in PEP 318 discussion threads had anything at all to do
with what was discussed by the references I found on
"decorators" (which were all about "design pattern" stuff).
So, I gave up and went back to work on writing a strip-chart
recorder using the Gnuplot module.

 

[Skip Montanaro]

1) That's not mentioned in PEP 318

We can fix that.

2) That's in disagreement with http://www.python.org/moin/PythonDecorators

That too (different authors, by the way).

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

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

Skip

 

[Arien Malec]

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

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

Google:

decorate "syntax tree" -pattern --> 129 hits
decorator "syntax tree" -pattern --> 20 hits
decorator pattern -"syntax tree" --> about 62,000 hits

Arien

 

[Skip Montanaro]

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:

...

BFD. Sure, there are tons more application programmers in the world than
compiler geeks, so Google returns many more hits for GoF-style decorators.
So? 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).
Hell, when someone says "decorator" I usually think of "Queer Eye for the
Straight Guy". <wink>

now-where-were-my-fabric-swatches?-ly, y'rs,

Skip

 

[Arien Malec]

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

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.

Arien

 

[Colin J. Williams]

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

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.

Arien

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.

The Mad Hatter's response to Alice dealt with the root naming issue:
"When I use a word," Humpty Dumpty said in rather a scornful tone. "It
means just what I choose it to mean - neither more or less."

"The question is," said Alice, "whether you can make words mean so
many different things."
"The question is," said Humpty Dumpty, "which is to be master - that's
all."

Colin W.

 

[Arthur]

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
superficially 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]

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