"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Bengt Richter" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > 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
--
http://mail.python.org/mailman/listinfo/python-list
