Edvard Majakari wrote:
> Hi,
>
> My idea is to create a system working as follows: each module knows
> path to plugin directory, and that directory contains modules which
> may add hooks to some points in the code.
>
> Inspired by http://www.python.org/pycon/2005/papers/7/pyconHooking.html
>
> I would create a class like this:
>
> class Printer:
>
> def printit(self, msg):
> stuff = self.beforePrintHook(msg)
> if stuff:
> msg = stuff
> print msg
> self.afterPrintHook(msg)
>
> def beforePrintHook(self, msg): pass
> def afterPrintHook(self, msg): pass
>
> Now, in the spirit of py.test, I'd like API to be practically no API at all :)
> moreover, deploying a plugin must consist simply of adding appropriate file to
> plugins directory, nothing more, and removing it would uninstall it. The
> plugin should be able to somehow result in all future invocations to
> Printer.printit() call hooks specified in the plugin. Now, the plugin module
> for class above /might/ be along the following lines (I'm thinking of stuff
> here, so I don't know yet what would be the most appropriate way):
>
> ### a very simple plugin which uppercases all data fed to it.
>
> extensions = {'Printer': 'PrinterHook'}
>
> class PrinterHook:
>
> def beforePrintHook(self, msg):
> return msg.upper()
> def afterPrintHook(self, msg):
> print "Called afterPrintHook with msg %s" % msg
>
>
> Now, I have a very rude (I think) implementation which has two methods, first
> the one that loads plugin modules:
>
(snip code)
>
> But hey, this has many downsides. First off, mechanism doesn't support
> arbitrary namespaces. Here, class identifier in the plugin must be as it is
> seen from the module which calls the plugin (not a problem for me, but could
> be more elegant; probably a mapping between logical class identifiers and
> actual class names, hmm?). Second, if one wants to use many hooks (with
> priority for conflicts), it is not possible now; set_hooks always overrides
> potentially existing hooks. And probably many other problems that are not
> obvious to me, but for the simple purpose I have in mind, it seems to work.
Just a couple of ideas:
- using decorators for plugin hooks ? ie:
import hooks
class Whatever(anything):
@hooks.hook(for='Printer.beforePrintHook',priority=42)
def my_function_with_a_long_name(self, *args, **kw):
pass
The decorator would take care of "registering" the hook where relevant,
ie, storing it in a class attribute of the hooked class ?
which leads to:
- in the hooked class, use a dict class attribute for hooks:
from hooks import run_hooks
class Printer
# will be filled (and could even be created)
# by the @hook decorator
_hooks = {}
def print(self, msg):
# run_hooks will take care of selecting appropriate
# hooks (by looking up the class attribute _hooks)
# and running'em in order
msg = run_hooks(self, 'Printer.beforePrintHook', msg)
print msg
run_hooks(self, 'Printer.afterPrintHook', msg)
My 2 cents... I don't even know if this can be implemented (but I don't
see why it couldn't).
> This is the first plugin system in Python I'm writing, so I can be a way off
> the correct path..
<aol>
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
