Revised PEP 318 - Function/Method Decorator Syntax

Bernhard Herzog bh at
Tue Jun 10 15:35:21 CEST 2003

Kevin Smith <Kevin.Smith at> writes:

> Implementation Issues
>     In the following example there are two function decorators: 
>     synchronized(lock) and classmethod.  
>         def foo(self) as synchronized(lock), classmethod:
>             perform method operation
>     Since these all appear within the operation of the 'def' 
>     itself, it makes sense that synchronized, lock, and 
>     classmethod must exist at the time that the definition 
>     is compiled.


Surely you mean "when the def-statement is executed."

>     In addition, each of these arguments will be 
>     evaluated before being applied to the compiled function.  
>     This means that arguments like synchronized(lock) must 
>     return a descriptor that will be applied to foo.  Therefore, 
>     the code above translates to:
>         def foo(self):
>             perform method operation
>         foo = classmethod(<returned-descriptor>(foo))
>     In the example above, <returned-descriptor> refers to the 
>     descriptor returned by evaluating synchronized(lock).

Why not simply

        def foo(self):
            perform method operation
        foo = classmethod(synchronized(lock)(foo))

That makes it clear at which point the "synchronized(lock)" itself is
executed and that it has to return a callable object which will be
called with foo as argument without having to talk about

The only thing that is not clear to me is whether it's intended that the
function is actually bound to "foo" multiple times. OTOH, I'm not sure
it would really make a difference if it were only bound once at the end.

>     It could easily be argued that the descriptors should be applied
>     in reverse order to make the application of the descriptor look 
>     more like the resultant code.  I tend to prefer this form.
>         def foo(self):
>             perform method operation
>         foo = <returned-descriptor>(classmethod(foo))
>     In either case, the modified function is bound to the function
>     name at compile time.

Again, I think you mean "when the def-statement is executed."


Intevation GmbH                       

More information about the Python-list mailing list