decorators as generalized pre-binding hooks
tjreedy at udel.edu
Mon Jul 11 01:46:38 CEST 2005
"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
>> The twice monthly summaries should include this topic. As I remember,
>> 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
> Would something like the following count ?
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'
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
More information about the Python-list