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

Ronald Oussoren ronaldoussoren at mac.com
Thu Aug 5 21:28:13 CEST 2004

On 5-aug-04, at 21:17, Gustavo Niemeyer wrote:

Hi Bob,

Why are they special? Why should they be more important than any other part of the function definition? Because they take a function object as input and can do whatever they want with it and return something else. This seems extremely powerful. OTOH, perl is also powerful.

They should IMHO be a part of the function definition because they are part of the specification of what the function will do. In the current situation decorators are not part of the function definition.

def saveSheetDidDismissreturnCodecontextInfo(self, sheet, What is objc.signature() doing? objc.signature wraps the function object with an objc.selector that specifies specific return and argument types. In this particular case, it declares that the selector saveSheetDidDismiss:returnCode:contextInfo: returns void and takes an object and an integer as arguments. Without this, the selector can not be bridged correctly to the Objective C runtime and the program would crash. Isn't metaclass usage helpful in this case? Or a perhaps a dictionary? signature = {"funcname": "v@:@i"}

This moves the signature away from the function definition, meaning you have to take care to keep them synchronized.

or def funcname(...): ... funcname.signature = "v@:@i"

That should be workable for this specific example. It wouldn't work for the objc.accessor example. The objc.accessor function/decorator deduces the right kind of signature from the name and arguments of the function.

and a postprocessor like: objc.register(classname)

We already use a metaclass, which is working just fine ;)

The ctypes package behaves similarly and would use decorators for the same thing. I imagine that other runtime/language bridges would also benefit from similar techniques (Jython, IronPython, Python.NET, JPython.. or whatever else). I can also imagine it being used for things like XML-RPC, SOAP, Apple Events, COM, etc. in a similar manner. Is this something good? I mean, having function wrappers all around the place? Wouldn't it be introducing unobvious code (magic?) in packages which are working fine as they are?

Nobody is saying anything about modifying existing modules. Decorators might make it easier to write objects that implement a COM or AppleScript interface, that doesn't mean we have to convert existing modules into COM objects.

Should I just throw away my t-shirt with the "zen of python" text? :-) Please don't, people need to be reminded of the zen sometimes :-)

Ronald

More information about the Python-Dev mailing list