Descriptor/Decorator challenge

[Jack Diederich]

On Tue, Mar 06, 2007 at 11:44:48AM -0800, Arnaud Delobelle wrote:
> On 5 Mar, 18:59, "Arnaud Delobelle" <arno... at googlemail.com> 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