[Python-Dev] Call for defense of @decorators

[Ronald Oussoren]

On 5-aug-04, at 20:48, Gustavo Niemeyer wrote:

> Hello Ronald,
>
>> 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
>
> Why are they special? Why should they be more important than any other
> part of the function definition?
>
>> '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).
> [...]
>> 	@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.
>
> Is special syntax in the language really required in this case,
> considering you're already doing something "fairly magic" anyways?
>
> What is objc.signature() doing?

The argument is fairly magic, in that most people wouldn't know how the 
interpret it. The function itself is easy enough: it creates a custom 
method object. The meta-class for Objective-C classes extracts the 
method signature from that method object and uses it build the right 
method description on the Objective-C side of the bridge.

A special syntax for descriptors is not stricly necessary, we are after 
all already using them with Python 2.2 and Python 2.3 code. It does 
make life a lot easier, the method names used in my example are not 
particularly long, I sometimes uses much longer names (because I have 
to [*]). Having 3 copies of such a name increases the likelyhood of 
errors, and makes it harder to spot that all 3 names are the same.

To stretch a point: class syntax is also not necessary, instead of a 
class definition you can call type() with the right arguments. Does 
that mean we should do away with classes?
>
>> The generic example PJE is introducing in PEAK also seem a good 
>> usecase
>> for decorators with arguments.
>
> Any pointers?
>
> I'd really like to "see the light" of complex decorators, as oposed
> to KISS, and use the current language features to implement that.

Whoops, I used the wrong word, I meant 'generic functions' instead of 
'generic example'. He's doing something like this:

@when("isinstance(db, OracleDB")
def storeInDB(db, object):
	pass

@when("isinstance(db, BerkelyDB")
def storeInDB(db, object):
	pass

The 'when' decorator converts the function into a generic function that 
uses the expressions to dispatch to the right function implementation 
at runtime.

Ronald

[*] "have too" because I haven't found a good way to automaticly 
convert Objective-C method names in sensible shorter names. Objective-C 
has segmented method names, like smalltalk. This looks a little like 
keyword arguments:

@interface MyModel : NSObject
{}
-(int)sheetDidEnd:(NSSheet*)sheet returnCode:(int)code 
contextInfo:(void*)context;
@end

This looks like a method with 2 keyword arguments, but really isn't. 
The method name is 'sheetDid:returnCode:contextInfo:'. I convert that 
to a python identifier by replacing colons by underscores. That's an 
easy to remember rule, which means I don't have to replicate the vast 
amount of Cocoa documentation, but you do end up with some ungainly 
method names.

The only way I see to fix this is to introduce segmented method in 
Python, but I don't think that would fly :-) :-)