[Python-Dev] Re: Decorator order implemented backwards? (original) (raw)

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 comfuncdef (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