Another try at Python's selfishness

[Paul McGuire]

<n.estner at gmx.de> wrote in message
news:1138928166.272387.51110 at g44g2000cwa.googlegroups.com...
> Definitely looks interesting. I'd like it more if it was more explicit,
> but still, it does look nice.
>
> I guess you could make it recursion-safe if you saved/restored the
> global "__" variable before/after calling the actual function, and
> probably there's a way to make it thread-safe, too. But how would you
> make it generator-safe? Also, wouldn't lambda's you pass around from
> object to object be bound to use the wrong instance? How would you fix
> this code:
>
> class TestA:
>     @memberFunction
>     def do(f):
>         print f()
>
>
> class TestB:
>     @memberFunction
>     def do(x):
>         x.do(lambda : __)
>
> TestB().do(TestA()) # should print out TestB, does print out TestA
>
>
> There really should be something like a wiki for
> "selfishness"-proposals with pros and cons, so I could have looked at
> some before thinking about my own one...
>
Here's another pass:

__ = None  #initialize global __
def memberFunction(f):
    def func(self,*args,**kwargs):
        global __
        save__ = __
        globals()["__"] = self
        try:
            return f(*args,**kwargs)
        finally:
            __ = save__

    func.__name__ = f.__name__
    func.__doc__ = f.__doc__
    func.__dict__.update(f.__dict__)
    return func


class Test:
    @memberFunction
    def __init__(x,y):
        __.x = x
        __.y = y

    @memberFunction
    def mult():
        "Multiply the two member vars"
        return __.x * __.y


t = Test(5,4)
print t.mult()
print dir(t)
print t.mult.__doc__

class TestA:
    @memberFunction
    def do(f):
        print f()


class TestB:
    @memberFunction
    def do(x):
        z = __  # lambda's shouldn't directly reference '__'
        x.do(lambda : z)

TestB().do(TestA())

Prints out:
20
['__doc__', '__init__', '__module__', 'mult', 'x', 'y']
Multiply the two member vars
<__main__.TestB instance at 0x009DA4E0>