From http://www.ddj.com/web-development/184406073
Usually, most decorators expect a function on input, and return either a function or an attribute descriptor as their output. The Python built-ins classmethod, staticmethod, and property all return attribute descriptors, so their output cannot be passed to a decorator that expects a function. That's why I had to put classmethod first in Listing Four. As an experiment, try reversing the order of @traced and @classmethod in Listing Four, and see if you can guess what will happen. Curt Hagenlocher wrote: > This is really more of a Python question than an IronPython question, > but I'm not currently on any non-Iron Python lists. :) > > The following definition results in an error under both CPython 2.5 > and IronPython. Decorating a method as static or class prevents > attributes being set on the resulting definition. > > def decorate(obj): > obj.decorated = True > return obj > > class X: > @decorate > @staticmethod > def foo(): > pass > > Does anyone know the "why" of this behavior? > > I can work around this problem by declaring the decorators in the > opposite order, but it seems like an odd imposition to put on the > consumers of the code in question. I'm worried that I'm missing > something about the expected semantics of these standard functions. > > -- > Curt Hagenlocher > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
