[Python-Dev] Re: method decorators (PEP 318)
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