RELEASED Python 2.4, alpha 2

[Christopher T King]

On Fri, 6 Aug 2004, Anthony Baxter wrote:

> Please feel free to actually provide reasons for not liking @decorators.

or [decorators], or what have you:

What does one do if a decorator raises an exception?  If it's something 
necessary to the functioning of the code (say, classmethod or 
staticmethod), then all is as it should be.  But what if it's not?  What 
if you're using a run-time type checking library, or a code optimizer, 
that may not be installed?  In that case you would most likely want to let 
that decoration fail silently.  To get around this, you'd either have to 
rewrite that decorator and any above it in the chain as just normal 
decorations, or use some other weird hack.

Decorators in general are the right solution for the wrong problem (as I
detailed in another thread).  They are being introduced much too
prematurely, and have not been given time to be able to have been thought
through well enough.  The @ syntax is the result of trying to shoehorn too
many solutions into one fix.

They purport to solve the problems of function type declaration
(class/static), function attributes, runtime type checking, and general
function mangling, when each of these (save general function mangling)
already have distinct solutions in nearly every other language.  The first 
three problems are currently implemented as hacks in Python that happen to 
fall under the category of "general function mangling".  Streamlining the 
hack is not the answer.