On Sun, 2011-08-07 at 22:14 +1000, Nick Coghlan wrote:
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).
It seems to me, many of the attempts to improve functions involve making them more like objects. Since functions are a key building block of class's, I'd rather see functions simplified rather than made more complex. Which probably isn't possible at this time. As for a new way/direction ... Maybe a simplified function as a method may be possible? With that, it then becomes possible to have a Function class that people can alter by adding additional methods to. Then "def foo(): pass" could possibly be short for ... class f(Function): method __call__(self): #can this be more efficient over def? pass foo = f() Yes, functions are objects now, but modifying them is almost always hackish. Maybe moving in this direction can lead to some non-hackish alternatives for those use cases. Cheers, Ron