[Python-ideas] Access to function objects

Nick Coghlan ncoghlan at gmail.com
Sun Aug 7 14:14:18 CEST 2011


On Sun, Aug 7, 2011 at 4:17 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 8/7/2011 12:32 AM, Eric Snow wrote:
>> Of the three code blocks, functions are the only ones for whom the
>> resulting object and the execution of the code block are separate.  So
>> a code object could be executing for the original function or a
>> different one that is sharing the code object.
>
> Now I remember that the separation between code object and function object
> and the possibility of reusing code objects has been given as a reason to
> reject the idea. On the other hand, reusing code objects is so rare that I
> question the need to cater to it much.

Nested function objects and class definitions say 'Hi!' - they reuse
code blocks all the time. In the following code:

def decorator(f):
    @wraps(f)
    def wrapper(*args, **kwds):
        return f(*args, **kwds)
    return wrapper

All of the 'wrapper' instances share a single code object (stored as a
constant in the code object for 'decorator').

If a proposal suggests storing mutable state on a code object it's
time to stop and think of a new way (or drop the idea entirely).

>> Why not bind the called function-object to the frame locals, rather
>> than the one for which the code object was created, perhaps as
>> "__function__"?
>
> I do not understand this.

I'm fairly sure I do understand it, and I don't think it could be made
to work in a sensible way (either thread safety problems or else
thoroughly confusing interactions with the descriptor machinery).

I don't see any fundamental limitations preventing the use of a magic
closure variable for __function__ along the lines of __class__ in PEP
3135 though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list