On Sun, Aug 7, 2011 at 4:17 PM, Terry Reedy <tjreedy@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@gmail.com | Brisbane, Australia