[Python-Dev] Re: method decorators (PEP 318) (original) (raw)

Paul Prescod paul at prescod.net
Sun Mar 28 10:19:32 EST 2004

Phillip J. Eby wrote:

At 12:54 PM 3/28/04 +0100, Paul Moore wrote:

Robert Mollitor <mollitor at earthlink.net> writes:

> It would be nice if transformer decorations were never allowed > "arguments". It would keep that list as short > and as tidy as possible. That's the sort of restriction I imagined that Guido was tending towards. While it's justifiable in this context, I would prefer to leave the option of using arguments available, in case someone comes up with a use where function attributes are inappropriate. It's inappropriate to use attributes of a function for attributes that logically belong to the decorator. For example 'synchronized(lockattr="baz")'. The 'lockattr' logically belongs to the synchronizing decoration. Declaring it in a separate location makes the whole thing harder to read/understand.

I came up with the idea of decorators and function attributes working together, but I chose at that time NOT to propose that decorators be restricted to bare words. (i.e. I disagree with Robert)

In some cases, the attribute really is an input to the decorator and other times it is an input to the framework. The most obvious example of the former is if a given decorator is allowed multiple times with various arguments:

def foo[bar(1,"a"), bar(5, "d")] func(self, x): pass

(Of course that's getting pretty nasty to parse visually but maybe it is worth it for some use cases)

But in the more common case, it is often the case today that frameworks allow programmers to associate information with functions and then "register" that function (or the class it is in) completely separately. I don't believe that this separation causes big problems.

It isn't that you are artificially passing a decorator argument as a function attribute. Rather, the decorator is designed to work on a function attribute the same way that Python itself is designed to work on magic attributes like doc or name or slots.

Paul Prescod

More information about the Python-Dev mailing list