RELEASED Python 2.4, alpha 2
Christopher T King
squirrel at WPI.EDU
Thu Aug 5 19:12:40 CEST 2004
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
> 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
> 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
.accepts = (int,int,int)
.returns = str
> 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 ;)
More information about the Python-list