A decorator syntax not yet mentioned (I think!)

Mark Bottjer mark_bottjer at hotmail.com
Fri Aug 13 16:48:34 EDT 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.

   -- Mark



More information about the Python-list mailing list