[Python-Dev] @decorators, the PEP and the "options" out there?

[Bob Ippolito]

On Aug 5, 2004, at 10:07 PM, Greg Ewing wrote:

> "Phillip J. Eby" <pje at telecommunity.com>:
>
>> I updated the Wiki page, and added another syntax, the original "def
>> function() [decorator]:" syntax.  Interestingly, it looks like one of 
>> the
>> options with the most pluses and fewest minuses of any syntax you've 
>> listed
>> on that page; it's only ugly for long decorator definitions, and 
>> Guido said
>> he didn't care if a syntax was ugly.  :)
>
> Moreover, it seems to me that the main use cases proposed for long
> decorator expressions would be served just as well, or perhaps even
> better, by a convenient way of specifying function attributes,
> together with a suitable metaclass.
>
>   def aMethodWithAnInt_andAString(self, x, y):
>     @signature = "is"
>     ...
>
> To me, that seems like a more logical place to put something like a
> signature for an external function interface. It's a detail of
> interest to the implementor of the function, but not to its user, so
> putting it above the "def" gives it too much prominence.
>
> Also, putting anything up there (especially something long) tends to
> interfere with one's ability to scan down a list of defs looking for a
> function name.
>
> I hope Guido will see these arguments as being rational ones about
> usability and not irrational ones about aesthetics. At the least,
> perhaps they could be included in the PEP for posterity.

While using metaclasses makes a lot of things possible, I don't believe 
they are appropriate for this purpose.  Decorating functions and 
methods have nothing to do with the class, why should the class have to 
change in order to support it?  What about bare functions?  Metaclasses 
can become difficult to use and understand when you're using several of 
them at once.

If you look at it from another implementation standpoint, reasonable 
syntax for function attributes can be implemented rather easily with 
function decorators, but vice versa requires the use of metaclasses.  I 
think implementing decorators is the more reasonable choice.  Also 
consider how difficult it can be to integrate metaclasses into existing 
code, where decorators would not have this issue at all.

-bob