[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