Every couple of weeks I get a little time to work on this stuff... well, it's been a couple weeks. ;-) I was flailing last time over the issue of how to create objects that could be 'plugged' into different frameworks cleanly. One problem was that my existing framework had specific classes of objects that had specific methods associated with them.... I was having trouble working out how to use a 'generic' DataSkin in place of a specific object, say shopper, without having my DataSkin subclass somehow from the original shopper object. We were batting around the idea of putting the methods in the Specialist, rather than the object and have the specialist 'reach in and meddle' with the object itself... but now I see another way.. the generic dataskins could simply acquire the methods that they need from the specialist.... so rather than: MySkinManager.DoSomething( mySkin, etc... ) it could be mySkin = MySkinManager.retrieveObject( theObjectID ) mySkin.DoSomething( etc... ) where 'DoSomething' is a method of the Specialist MySkinManager, but it is only intended to be used (by acquisition) as a method of a 'managed skin...'. This all begs some questions.... (1) Is this 'reasonable'? Is anyone else using methods of specialists this way? (2) is it worth enforcing the use by acquisition? e.g., def DoSomething(self, etc... ): """ Do Something Cool.... """ if hasattr(self, '_isRackMountable'): ... continue with something cool... else: raise RuntimeError, "Sorry... this method must be acquired by a DataSkin.." (3) Has anyone found a better way to adorn 'plain' objects with methods? thanks! -steve