[Python-Dev] Re: 2.4a2, and @decorators
Bob Ippolito
bob at redivi.com
Wed Aug 4 16:50:24 CEST 2004
On Aug 4, 2004, at 9:46 AM, Jim Fulton wrote:
> Terry Reedy wrote:
>
> ...
>
>> Decorators will add complexity, regardless of syntax.
>
> Especially in their current over-powered form. If decorators didn't
> have to
> take arguments, then you could use a syntax like:
>
> def classmethod foo(cls, ...):
> ...
>
> This does add complexity, but I think it enhances understandability.
>
> I understand why some people want to be able to pass arguments to
> decorators,
> but frankly, I find many of the examples of doing so down right scary.
All of the important use cases I've found and seen for decorators have
arguments. PyObjC and ctypes (possibly Jython, IronPython) will use
them to specify the input and output argument types for a function
(integers, pointers, etc.). PJE has cooked up some interesting stuff
using decorators to do generic functions. I use these sorts of things
far more often than classmethod and staticmethod (or the like). I can
also imagine using them for something like decorating functions with
four character suite and event codes for responding to AppleEvents in
Mac apps.
I wouldn't really care for decorators at all if I couldn't use them to
these sorts of things. Your proposal would make decorators nearly as
bad as the current pre-2.4 situation. This is REALLY ugly:
foo = decorator(....)
@foo
def fun(....):
...
-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3589 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040804/ec2570d1/smime.bin
More information about the Python-Dev
mailing list