decorators as generalized pre-binding hooks

[George Sakkis]

"Terry Reedy" <tjreedy at udel.edu> wrote:

> "Bengt Richter" <bokr at oz.net> wrote in message
> news:42d02c21.231516573 at news.oz.net...
> > The binding of a class name is similar, and class decorators
> > would seem natural, i.e.,
> >
> >    @cdeco
> >    class Foo: pass
> > for
> >    class Foo: pass
> >    Foo = cdeco(Foo)
>
> 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 ?

@abstractclass
class AbstractFrame(object):

    @abstractclass
    @innerclass
    class AbstractPanel(object):
        pass

For one thing, it's more readable than the respective __metaclass__
declarations. Moreover, stacking two or more decorators is
syntactically straightforward, while for metaclasses you have to write
boilerplate code for making a subclass of the components, e.g.:
class AbstractInnerClass(AbstractClass, InnerClass): pass
Fortunately metaclasses are not that commonly used to cause
combinatorial explosion of such boilerplate classes.

> 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' ? And how
is this an argument against class decorators ?
 
George