Thanks for your response Chris ! Ha ! the job of the mad man is todo the things the are not "advisable" and see what gives. Like why it is not advisable and, if possible, their are ways to achieve things that are previously overseen. i already do a lot of travelling of the callstack to see from where a function is called. mostely for logging purposes, like what plugin registered this callback etc. lately i also had the need to log the variable name of a object, and the thought of be able to "break out of the namespace" concept got me thinking what i am thinking of is code that can examine the context it is run in. The object, when called can figure out in what kind of space it is living in and discover what kind of API other objects in the space offer. This is a pre function that gets called before the actual function/method and can thus determine if a certain request can be fullfilled. I bet a decorator could be made, in which i can assign certain caller context references into variables in the function/method ? I use 1 generic parameter object, in which i can stuff lots of things, but i rather have the function be able to see what is around ;] Think of sending JSON over the wire, reconstruct an object with it and then let the object figure out what it can and cannot do in this external environment. Code i use now is this: # life/plugs/context.py # # """ show context. """ ## basic import import sys ## context command def context(event): result = [] frame = sys._getframe() code = frame.f_back.f_code for i in dir(code): print("%s => %s" % (i, getattr(code, i))) del frame context.cmnd = "context" So much to explore ;]