On Sat, Aug 6, 2011 at 2:28 PM, Terry Reedy <tjreedy@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@rebertia.com> wrote:
On Sat, Aug 6, 2011 at 1:10 AM, David Townshend<aquavitae69@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@python.org http://mail.python.org/mailman/listinfo/python-ideas