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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4