On Tue, Mar 06, 2007 at 11:44:48AM -0800, Arnaud Delobelle wrote: > On 5 Mar, 18:59, "Arnaud Delobelle" <[EMAIL PROTECTED]> wrote: > [snip] > > Well in fact I couldn't help but try to improve it a bit. Objects now > > don't need a callerclass attribute, instead all necessary info is > > stored in a global __callerclass__. Bits that didn't work now do. > > OK that wasn't really thought through. Because I changed the design > mid-way through writing it __callerclass__ wasn't doing the right > thing. I've sorted the issues I could see and made it (hopefully) > thread-safe. I'm not going to pollute this list again with my code so > I've put it at the following address: > > http://marooned.org.uk/local.py >
I fooled around with this a bit and even when using different techniques than Arnaud (namely stack inspection and/or class decorators) it ends up looking the same. In order to pull this off you need to 1) mark the localmethods as special (@localmethod works here) 2) mark all non-localmethods as not special (metaclasses, class decorators, or module-level stack inspection) 3) keep track of the call stack (can be implemented as part of #1 and #2 but adds overhead regardless) Double underscore names take care of #1 at compile time and by definition anything not name-manged falls into the non-special class of #2. After that the special/non-special calls are given different names so the native call semantics take care of the call stack for you. With some bytecode manipulation it should be possible to fake the same name mangling by using just @localmethod decorators and adding some overhead to always checking the current class (eg A.m() for the function am()) and falling back on doing the normal call of self.m(). This could be made more exact by doing inspection after the fact with any of metaclasses/class decorators/module inspection because then we could inspect what is a @localmethod and what isn't all the way through the class tree. I could be wrong on the byte-hack part as I've only recently learned to read the chicken bones that are byte codes (thanks to PyCon sprints I got to spend time picking python-devs's brains over burritos). It seem plausible if fragile. -Jack -- http://mail.python.org/mailman/listinfo/python-list
