decorators as generalized pre-binding hooks

[Terry Reedy]

"George Sakkis" <gsakkis at rutgers.edu> wrote in message 
news:1121034087.932596.221010 at g43g2000cwa.googlegroups.com...
> "Terry Reedy" <tjreedy at udel.edu> wrote:
>> This possibility was discussed on the py-dev list about a year or so 
>> ago.
>> The twice monthly summaries should include this topic.  As I remember, 
>> the
>> reason for limiting to functions included:
>>
>> 1. classes have metaclasses, functions don't have metafunctions.  No one
>> gave an example for classes not handled at least as well with a 
>> metaclass.
>
> Would something like the following count ?
[snip]
Not qualified to comment.

>> 2. certain applications require long-function_names_like_this, for which
>> triple typing is substantially annoying and error-prone.
>
> I'm not sure what you mean here; where is the 'triple typing' ?

def long-function_names_like_this(arg1, b, xx , sklfjsl, uuuu):
  'body of fuction here'
  pass
long-function_names_like_this = \
  some_decorator(long-function_names_like_this)

And for the example I am thinking of (integrating Python with Objective-C, 
I believe), the above name is apparently not an exaggeration.

> And how is this an argument against class decorators ?

It is an argument for function decos that does not apply to classes.  The 
does not seem to be a similar need for long, convoluted, class names.  (And 
there is the metaclass option for classes that there is not for functions.) 
So, in relative terms, it is an argument that function decos are relatively 
more needed than class decos.  Given that the decision to add them all was 
a fairly closely balanced one, relative differences can tip the balance one 
way one time and the other way the other.

Guido did not permanently rule out class decos, that I know of, but he 
noted that it would be easier to add them later if really needed than to 
remove them later is not really needed.

Terry J. Reedy