RetroSearch Browse

Mon Aug 16 17:38:58 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-August/047880.html

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/047880.html below:

[Python-Dev] Re: Decorator order implemented backwards?