A decorator syntax not yet mentioned (I think!)
mark_bottjer at hotmail.com
Fri Aug 13 22:48:34 CEST 2004
Peter Hansen wrote:
> Mark Bottjer wrote:
>> Peter Hansen wrote:
>>> Mark Bottjer wrote:
>>>> With this
>>>> syntax, though, the decorate block changes how the def statement is
>>>> handled, even though they are at the same indentation level.
>>> Changes it how? The definition of this whole decorator idea has been
>>> that it is equivalent to applying the decorator functions *after* the
>>> def has completed, as in "func = decorator(func)". This does not
>>> in any way changed how the def statement itself is handled.
>> Except that the action happens magically after the def, even though
>> the decorator is before it. To me, this has the appearance of changing
>> the action of def. I'm trying to argue based on how it appears, rather
>> than how we know it to be implemented.
> I understand that. What I don't understand is why you make
> this complaint about the indented form, when the non-indented
> form with @decorator has exactly the same issue! In all
> cases, pre-def is weird in that the declarative lines that
> decorate the function lead to action *after* the def is
> closed, whether the decorators are indented or not.
I *do* have the same complaint about the @decorator form. *All* the
prefix forms have this problem. That's why I don't like them as much as
the "top of function block" forms; at least with those we have the
already-established pattern of docstrings to help us understand what is
going on. The "in-statement with def" forms are the cleanest
conceptually, but just don't seem to code up well.
My point was only that I find the indented block of decorators to be
less intuitive than the (ugly, but to me more obvious) flush-left list
of @decorators. If we're going to be stuck with a prefix form, I like
@dec better than decorate: (though "meta dec" would be fine as well).
I think GvR's point about not having to look inside the function to
determine its specification is nice in theory, but we're already used to
doing exactly that. Changing it now just adds confusion.
More information about the Python-list