Decorator syntax

John Roth newsgroups at
Thu Aug 5 23:01:42 CEST 2004

"Christopher T King" <squirrel at WPI.EDU> wrote in message
news:Pine.LNX.4.44.0408051601580.14462-100000 at
> On Thu, 5 Aug 2004, Istvan Albert wrote:
> > The disagreement is caused by trying to achieve a lot of different
> > things with one feature.
> >
> > Thus the solution that is emerging is to cram everything in
> > front of the function definition.
> Agreed!  Exactly!  Most of what people seem to want from decorators are
> a way to specify function types, do type checking, and give functions
> attributes / metadata.  As I've said before, these are seperable problems
> and should be treated as such.  What little left over that can
> benefit from general-purpose decoraters will likely not be enough to form
> a major use case.

To walk back into the fray; I've got three programs that I checked
whether I could use decorators. The two that needed metadata
I couldn't; the other one (which is in the vague "sometime-maybe" category)
I certainly can, but it would be a gross misuse of the facility.

The thing about metadata is very simple. After managing to get to the
bottom of the domain model, I find that I need to associate metadata
with specific identifiers in certain classes. Note that this is with the
identifiers, NOT with the objects that are bound to the identifiers.
The metadata applies regardless of what object is bound to the
identifier, and regardless of whether it is bound in the class or instance.
(Of course, if there is an object bound to the identifier, it needs to
conform to what the metadata says, but that's a different issue.)

In the second program, I find a need to supply metadata that is
related to the class, and not to any particular identifier or object
in that class. (Of course, I also need to supply metadata for certain

In the third program, I need a convenient way of putting function
definitions into instances; the decorator facility can do this as a
side effect. That's what I meant by a gross misuse of the facility,

John Roth

More information about the Python-list mailing list