RELEASED Python 2.4, alpha 2
anthonybaxter at gmail.com
Thu Aug 5 18:41:10 CEST 2004
On Thu, 5 Aug 2004 12:29:51 -0400, Christopher T King <squirrel at wpi.edu> wrote:
> 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.
Silently failing is completely non-pythonic. If you really wanted to
handle a missing decorator, something like
missingdec = lambda x:x
would do this for you.
> 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.
Too prematurely?? staticmethod and classmethod were introduced in 2.2!
PyObjC, ctypes, Jython and IronPython can all do with using them, as can
rather a lot of other chunks of code. Anything that applies metadata to
functions can use this - look at all the various places where people are
putting stuff in docstrings as a current hack.
> 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.
Or, alternately, they're another tool in the toolbox, along with
More information about the Python-list