RELEASED Python 2.4, alpha 2

[Anthony Baxter]

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?  

def deco(func):
      raise TypeError

@deco
def foo():
    print "hello"



> 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
metaclasses and
the like.

Anthony