[Python-Dev] Call for defense of @decorators

[Gustavo Niemeyer]

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