Plugins accessing parent state

[Bruno Desthuilliers]

André a écrit :
> On Mar 28, 6:39 am, "hajdu... at gmail.com" <hajdu... at gmail.com> wrote:
>> On Mar 28, 1:58 am, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
(snip)
>>> 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)
>> ...
>> plugin.do(msg,self.utilities)
> 
> I would bypass the step of creating a new instance and write instead
> plugin.do(msg, 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:

     plugin.do(msg, RestrictedSelf(self))

<mode='xp-guru'>
But my bet is that YAGNI, so to make a long story short: start with the 
simplest thing that could possibly work !-)
</mode>

HTH