I understand the motivations, but I think using setattr to pass params to plugins isn't a good choice. It makes it super easy for plugin developers to wind up with weird exceptions.
Specifically, if you're writing something like the multiprocessing plugin, where parameters get passed on to some delegate object, if you don't make sure your override of setattr checks whether that delegate object exists before checking whether it defines whatever parameter you'd like to pass it, you'll run into exceptions any time you try to set a property of your plugin. Usually, this means your plugin class can't get past init.
A more robust approach would be to have subclasses implement setParam() and getParam() methods, then store params however they like.
I understand the motivations, but I think using setattr to pass params to plugins isn't a good choice. It makes it super easy for plugin developers to wind up with weird exceptions.
Specifically, if you're writing something like the multiprocessing plugin, where parameters get passed on to some delegate object, if you don't make sure your override of setattr checks whether that delegate object exists before checking whether it defines whatever parameter you'd like to pass it, you'll run into exceptions any time you try to set a property of your plugin. Usually, this means your plugin class can't get past init.
A more robust approach would be to have subclasses implement setParam() and getParam() methods, then store params however they like.