[Python-ideas] Access to function objects

[ron3200]

On Sun, 2011-08-07 at 22:14 +1000, Nick Coghlan wrote:
> 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).

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