[Python-Dev] Re: metaclass and author are already decorators (original) (raw)

Paul Morrow pm_mon at yahoo.com
Sun Aug 22 16:15:11 CEST 2004

Martin v. Löwis wrote:

Paul Morrow wrote:

The items you describe are not decorators, they are attributes. The current syntax for decorators is 'x = decorator(x)'.

In today's Python that's of course true, but these 'attributes' are used to supply meta info about the class. They describe the class. They are never intended to be inherited by instances of the class. So in this sense, they are very much more like decorators than (normal) class attributes. No, that makes them completely unlike function decorators. Function decorators do not describe something, they modify something (namely, the thing that is bound to the function's name).

That's a terrible way to 'think' about this kind of programming --- programming thru imperative mutation. Ugh. It's much better to say "this function is synchronized and memoized" than to say "apply the synchronized mutator to this function, then apply the memoized mutator to the resulting function". So regardless of what is going on under the hood, it's better to think of this technique as a function annotation --- something additionally stated in its description --- than something that we do to the function.

Some attributes have a run-time meaning, like metaclass; others, like author, have not. Unfortunately, the meaning of metaclass is conceptually different from decorators: the metaclass is evaluated before the class is constructed; the decorators are evaluated after the function is constructed.

When a feature gets added/applied to a class/function shouldn't matter to the programmer. We've screwed up if we make them think that hard. They should simply be able to state which features they want a class/function to have (as they can now with metaclass, lt, etc.), and the system makes sure they are there when the class/function is called. It's magical, but its easy to think about.

So providing definitions for xxx attributes is not done for the same purpose as the other attributes. They are special. Therefore, let's formally acknowledge that and call them 'decorators'.

I acknowledge that they are special, and call them "special attributes". I won't call that decorators, because that means something else.

But it shouldn't, because they ("special attributes" and "decorators") fundamentally have the same purpose --- to make something magical happen to the function/class. You're getting hung up on what's going on under the covers and looking at the differences there. That should be irrelevant to the programmer. It's magic. All they need to know is what magic happens when they use an xxx attribute and what they must do to use it properly --- and the later should be as easy as possible.

2. All magic methods in today's Python are invoked 'magically' (are called indirectly; not called directly by any user code).

Correct. For each special attribute, the interpreter needs advance knowledge of the name of the attribute. Not so for decorators: the interpreter does not need advance knowledge - you can define your own function decorators, and Python will support them because of the leading @.

Another way to look at that is that the interpretor has some built-in magic and you can create your own. But it's all still magic. And that makes it easier to think about.

More information about the Python-Dev mailing list