[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