RELEASED Python 2.4, alpha 2
Christopher T King
squirrel at WPI.EDU
Thu Aug 5 18:29:51 CEST 2004
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.
More information about the Python-list