[Python-Dev] Call for defense of @decorators (original) (raw)

Ronald Oussoren ronaldoussoren at mac.com
Thu Aug 5 21:07:18 CEST 2004

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 saveSheetDidDismissreturnCodecontextInfo(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 :-) :-)

More information about the Python-Dev mailing list