[Python-ideas] Access to function objects

[Eric Snow]

On Sat, Aug 6, 2011 at 2:28 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 8/6/2011 4:19 AM, Chris Rebert wrote:
>>
>> On Sat, Aug 6, 2011 at 1:16 AM, Chris Rebert<pyideas at rebertia.com>  wrote:
>>>
>>> On Sat, Aug 6, 2011 at 1:10 AM, David Townshend<aquavitae69 at gmail.com>
>>>  wrote:
>>>>
>>>> Has anyone else ever thought that it might be useful to access a
>>>> function
>
>> [Rejected] PEP 3130: Access to Current Module/Class/Function
>> http://www.python.org/dev/peps/pep-3130/
>
> The first problem with this is that it is three proposals in one. Each
> should have been considered separately on its own merits. The second problem
> stems from the first: there is a blanket rejection of all three with no
> reference to the relative merits of the three different proposals.
>
> The __module__ proposal is particularly weak as the only use case given is
> replacing
> if __name__ == '__main__': ...
> with
> if __module__ is sys.main: ...
> I would reject the collective proposal just to reject this.
>
> The __class__ proposal seems to have been dealt with partly by revisions to
> super. I have not read it enough to know if anything more is left, but there
> is not much, if any, demand for more that I have seen.
>
> The proposal for access to a function from within the function has two
> important use cases, mentioned in the PEP. First is to make truly recursive
> functions. Second is to dependably access function attributes from within
> the function. (Without that, there are hardly used even a decade after their
> introduction.) In both cases, the idea is to make the function operate as
> desired independently of external namespace manipulations (even from outside
> the module) that the function and its author literally have no control over.
> Except purely for speed, function attributes could then replace
> pseudo-parameters with default args.
>
> This proposal/desire comes up constantly on python-list, generally with
> support. I believe it was part of two recent threads. I would like to know
> if the rejection of the idea so far is a rejection in principle (and if so,
> why) or a rejection of specifics.

+1

Maybe a more straightforward effort would be appropriate if the other
ideas sank the function part.  Here's my 2c on how to make it work.

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.

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__"?  To finish things off, bind to every new code object
the function for which it was created, perhaps as "co_func".  That way
you will always know what function object was called and which one the
code object came from originally.

No new syntax.  One new attribute on code objects.  One new implicit
name in locals().  Code to add the function object to the code object
at definition time.  Code to add the [other] function object at
execution time.

-eric

>
> --
> Terry Jan Reedy
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>