Using metaclasses to play with decorators.

[Michael Sparks]

On 15 Jun 2004, Michele Simionato wrote:

> The problem of metaclasses-based solutions is that they are hacks.

Agreed.

> We don't want everybody to implement his/her version of decorators
> (yes me too I have implemented mine).

I was only doing so to toy with them to see what it would offer since it
was clear from the talk that there was interest in what the community at
large thought, so I thought I'd have a go and find out what I thought.

By doing so I came to the viewpoint of why have __doc__ ? Why not have
access to whatever the first object is - as far as this is practical? If
it's a dict, so be it, if it's a string, so be it, but provide a uniform
way of accessing. (eg func.__meta__ perhaps)

I also came to the opinion that having access to that object is orthoganal
though complementary to decorators. Without metaclasses I simply would not
have played around with the ideas, and that's the only area I feel
comfortable with metaclasses at present - playing with ideas.

However, your point:

> Decorators MUST be in the core language. Waiting will only favor the
> abuse of metaclasses.

Is something I hadn't considered, and perhaps alot of the people prepared
to wait beyond 2.4 for a "better" syntax hadn't considered because they
hadn't realised something like it could be done using metaclasses.

Indeed, if I hadn't seen Theo de Ridder's excellent talk I certainly
wouldn't've considered the idea. I'm not sure I would want to use python
that why myself, but it was impressive.

Based on playing with metaclasses for different aspects, I might've voted
for Guido's preferred syntax instead if that possible aspect had been
raised rather than voting to wait.

> ...
> *without* the ability to specify multiple decorators (i.e. let compose
> the multiple generators explicitely by hand, with a functional.compose
> function or something like that).

What if the decorators are things like author, grammar rules, type hints
(maybe) for external language bindings etc?


> But I prefer to have a syntax I don't like 100% then waiting for another
> year or so. Why don't put a given syntax in 2.4a, see how it goes, and
> change it in 2.4b if it is the case?

That was part of the rationale behind the "final" decorated_class_four
metaclass - it allows any syntax you like, you just have to be prepared to
parse whatever structure you put in the doc string.

If you 'replaced' the doc string with a (say) doc object (or meta object),
then some of the usecases for decorators disappear, leaving just the cases
regarding transformation of the function type. That means whatever syntax
you do choose for transformational decorators _might_ be less of an issue.
(I'm not a huge fan of changing syntaxes though, which might well be why I
like the idea of a doc/meta object)

I've no idea how complex such a change would be however, and I suspect at
this point I'm retreading ground others have gone over already.


Michael.