Cast into custom type

[Henning Bredel]

Gabriel,

thanks for your reply. See my comments below.

On Tue, 03 Nov 2009 21:31:27 -0300, Gabriel Genellina wrote:

> En Tue, 03 Nov 2009 09:07:01 -0300, Henning Bredel
> <henning.bredel at gmx.de> escribió:
>> On Tue, 03 Nov 2009 10:18:29 +0000, Steven D'Aprano wrote:
> 
> Then forget about the code you read in that blog post, doesn't apply to
> your use case.

Well, but it shows how to mount plugins into the application without
creating instances instantly. I only use one plugin/module at a time,
so I'd like to avoid holding instances which aren't used.

If the solution from the blogpost are meant completely different, 
I'd appreciate if you could point me on some concrete arguments why I
shouldn't realize plugin mechanism in that way.

BTW: I made it work now (was only a(nother) misinterpretation of how
a callable should look like.
 
> Try something like this:

[...]

> class PluginManager:
>      def __init__(self, plugin_directory):
>          self.plugin_directory = plugin_directory self.plugins = []
> 
>      def load_all(self):
>          for fn in glob(os.path.join(self.plugin_directory, '*.py')):
>              namespace = {}
>              execfile(fn, namespace)
>              for name, obj in namespace.items():
>                  if (isinstance(obj, type) and
>                      issubclass(obj, Plugin) and
>                  obj is not Plugin):
>                      # obj is a Plugin subclass
>                      cls = obj
>                      print cls.__name__, fn
>                      print cls.__doc__
>                      print
>                      plugin = cls(self)  # call the constructor
>                      self.plugins.append(plugin)

[...]

Yes, I get your point. But you instantiate all available plugins. I'd like
to avoid that. Will a callable like `plugin().initialize' avoid
that, or is an instance created immediately when passing this callable?

> Plugin is the base class; all plugins must inherit from it. PluginMgr
> scans the plugin directory, executes all modules it finds there (be
> careful...), and looks for Plugin subclasses. Then creates an instance
> of each Plugin subclass.

Well, as far I understand it, I'd say that the ActionProvider class from
the blogpost is the (nearly) the same as your Plugin base class. All new
plugins has to implement the abstract ActionProvider class. The module
loading/recognizing is done by my main application. So what would be the
main difference here?

Thanks for your advice

  Henning