[Python-Dev] Call for defense of @decorators

[Ronald Oussoren]

On 5-aug-04, at 18:36, Guido van Rossum wrote:

> It seems a public outcry against @decorators has started.  When I let
> Anthony check it in for 2.4a2, the plan was to see how it fares in a2
> and a3, and possibly take it out in 2.4b1.  If you don't want that to
> happen, you might want to say something in public in defense of
> @decorators.

The outcry seems to be the same discussion as ever :-(

I'm in favor of @decorators. It's easy to notice them when the are 
present and they are clearly special. The '[decorator] def ...' and 
'decorate(decorator) def ...' are very magic, and are IMHO unfriendly 
to newbies (you must metion them in any introduction to python, because 
otherwise users would complety mis the signicance of the decorations).

My particular use-case is PyObjC, which sometimes suffers from haveing 
veryLong_andSometimesAlsoVeryUgly_methodNames_. Having to repeat those 
three times when using a decorator is no fun. The only usage for 
decorators in PyObjC is for specifying Objective-C method signatures, 
which is sometimes required for the correct functioning of methods (I 
do try to deduce the correct method signature from methods in base 
classes and Objective-C protocols, but's that not always necessary).

Some examples:

class ModelObject (NSObject):

	@objc.accessor
	def messageLength(self):
		return "XIV"

	@objc.signature("v@:@i")
	def saveSheetDidDismiss_returnCode_contextInfo_(self, sheet, 
returnCode, contextInfo):
		pass

The argument to objc.signature is fairly magic and I do try to abstract 
it away (such as with the introduction of objc.accessor), but that's 
not always possible. If decorators were not allowed to have arguments 
I'd have to introduce temporary functions that wouldn't help in 
readability.

The generic example PJE is introducing in PEAK also seem a good usecase 
for decorators with arguments.

Ronald