RELEASED Python 2.4, alpha 2

[Christopher T King]

On Fri, 6 Aug 2004, Anthony Baxter wrote:

> 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"

Yes yes yes, I /know/ they are /able/ to raise exceptions.  My point was 
about handling them in a clean, concise way.

> Silently failing is completely non-pythonic.

Then let's say you want to print a warning, "Warning, type checking not 
installed!"

> If you really wanted to handle a missing decorator, something like
> missingdec = lambda x:x would do this for you.

Ick.  That doesn't fix the general case (though I admit it wouldn't come 
up too often).

> > 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!

I'm referring to the syntax, not the decorators themselves.

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

Anything that applies metadata to functions can use function attributes 
much more effictively.  They're cleaner, more to the point, and are likely 
to have much less backlash than @.  Example of a previous function 
attribute proposal:

 def foo(a,b,c):
     .accepts = (int,int,int)
     .returns = str
     pass

> Or, alternately, they're another tool in the toolbox, along with
> metaclasses and the like.

It just so happens I'm not a big fan of metaclasses, either ;)