Plugins accessing parent state

Bruno Desthuilliers bruno.42.desthuilliers at
Fri Mar 28 12:31:33 CET 2008

André a écrit :
> On Mar 28, 6:39 am, "hajdu... at" <hajdu... at> wrote:
>> On Mar 28, 1:58 am, "Diez B. Roggisch" <de... at> wrote:
>>> But to be honest: you are thinking much to far there - after all, it's
>>> all *your* code, and inside one interpreter. A real isolation isn't
>>> available anyway.
>>> So just do what fullfills the functional requirements.
>> Since I want to have a uniform call to all plugins, would it make
>> sense to split out the attributes that I do want to share to a
>> separate class and then simply create a new instance of that class and
>> store it in the main class?
>> For instance
>> ...
>> self.utilities = Utilities(self)
>> ...
> I would bypass the step of creating a new instance and write instead
>, self)
> thus having access to all properties/methods of the calling object.
> Why restrict it?...

+1 on this.

And FWIW, *if* you later find out you *really* need to restrict access 
to the caller object's attribute (ie: 'self'), it will be as simple as 
wrapping it in a decorator (design pattern, not function decorator) 
object that will take care of this, ie (Q&D naive implementation):

class RestrictedSelf(object):
    allowed_attributes = ('dothis', 'dothat')
    def __init__(self, realself):
       self.realself = realself
    def __getattr__(self, name):
       if name.startswith('_') or name not in self.allowed_attributes:
           raise AttributeError(
               'access to %s.%s is forbidden' % (self.realself, name)
           return getattr(self.realself, name)

And in the call to the plugin:, RestrictedSelf(self))

But my bet is that YAGNI, so to make a long story short: start with the 
simplest thing that could possibly work !-)


More information about the Python-list mailing list