[Python-Dev] Re: Decorator order implemented backwards?
Phillip J. Eby
pje at telecommunity.com
Mon Aug 16 17:38:58 CEST 2004
At 12:38 AM 8/16/04 -0400, James Y Knight wrote:
>On Aug 15, 2004, at 11:45 PM, Jack Diederich wrote:
>>My patch to add support for class decorators defines func before the
>>decorators as a side effect of moving Mark's decorator code out of
>>com_funcdef (and yes, that was a plug).
>
>That's definitely worse. It causes a possibly incorrect temporary value to
>be bound, even if only for a short amount of time. The current behavior of
>only doing the store after executing the decorators is cleaner.
Not only that, it's the behavior *required* by the PEP. Note that it
states "*without* the intermediate assignment to the variable
func". (Emphasis added.)
This choice of semantics is intentional, to allow for things like Ed
Loper's property_getter/property_setter and generic functions to be
possible. That is, it's intended to allow for decorators that construct an
object from multiple function definitions. Such decorators need to be able
to get the previous object bound to that name, and that's not possible if
the new function has been saved under that name.
There should probably be some kind of test added to the test suite to
verify this behavior, and adding an explanation to the PEP is probably in
order as well.
More information about the Python-Dev
mailing list