Cast into custom type

[Gabriel Genellina]

En Wed, 04 Nov 2009 10:52:51 -0300, Henning Bredel <henning.bredel at gmx.de>
escribió:

> On Tue, 03 Nov 2009 21:31:27 -0300, Gabriel Genellina 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.

Ah, I see. Well, but you don't have to do anything special to collect  
plugin subclasses
-- somebaseclass.__subclasses__() returns a list with all direct
subclasses, without requiring a custom metaclass. This recipe [1] shows  
how to  recursively collect all of them.
(Perhaps some people prefer the metaclass approach, but not me)

> 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().initialize() creates a plugin instance, calls its initialize
method, and then discards the instance.
You probably want to create a plugin instance, store it somewhere as the
"current plugin", call its initialize method, and use the "current plugin"
to do some work.
(Or, are the missing () after plugin().initialize intentional? Yes, this  
is a bound method, and it knows the plugin instance from which you got it.  
The instance is created at the time you ask for the bound method. You may  
call it later at any time. I'd probably use a bound method like that only  
if "initialize" is the only method you ever call on the plugin instance.  
In other cases, I'd store a plugin instance somewhere as described above.

> 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?

Instead of relying on a custom metaclass, I excplicitely scan all module  
objects, testing for subclasses. That's all my code does, no rocket  
science involved :)

[1] http://code.activestate.com/recipes/576949/

-- 
Gabriel Genellina