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

Gustavo Niemeyer niemeyer at conectiva.com
Thu Aug 5 21:52:01 CEST 2004

>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.

Ok, I understand that for objc case, extra magic is needed to make the system work. OTOH, is this kind of magic usual enough to justify adding extra syntax to the language? Won't it encourage usage of this facility abusively (as was just mentioned with SOAP, XML-RPC, Jython, IronPython, ...), making it inherently less readable?

For example, someone mentioned the following URL:

http://rafb.net/paste/results/bKBUem36.html

Which provides:

def magicprop(f): return property(*f()) class Foo(object): @magicprop def bar(): def get(self): ... def set(self): ... return get, set

Notice that bar() is actually called inside the decorator.

>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.

This might be spelled as:

class C: signature = {}

signature["f"] = "@v:@p"
def f(self):
    pass

>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.

So why does it need to be run together with the function definition?

>and a postprocessor like: > >objc.register(classname)

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

Cool! Glad to know about another interesting metaclass usage.

[...]

>>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.

Yes, that's what I was talking about. Current modules already work fine, and I haven't seen usage cases that would benefit from the complex (or, more powerful) decorator syntax in a way that couldn't be easily spelled some other way.

-- Gustavo Niemeyer http://niemeyer.net

More information about the Python-Dev mailing list