Am 14.02.10 13:05, schrieb Florian Ludwig:
On Sun, 2010-02-14 at 10:16 +0100, Paul Kölle wrote:
Am 13.02.2010 10:50, schrieb Florian Ludwig:
Hi,
I'm looking for a module/plugin/intra-process-communication/hook system
for python. Maybe someone here could point me to some project I missed
or might have some good ideas if I end up implementing it myself.
[...]
The plugins you wrote probably import them from the wiki module directly
which means your blog would depend on the wiki. (?!) So where to put the
interface/[...] definition that is imported by those plugins? Create a
package/module just containing the interface? This really get
troublesome if different people wrote the wiki, the blog and another
third one a plugin.
If you are talking about code sharing you can move the common code out
of your applications in a seperate namespace. If you follow the model
trac is using you would install a module/package/egg with the basic
functionality of the pluginsystem (i.e. what's in core.py and env.py +
logging and whatever you think is necessary).
All shared code like your auth-plugins would go in a common plugin
directory to which you can refer via PYTHONPATH.
You're right, its about code sharing/reusing - should have said it more
clearly. What I am looking for is the pluginsystem that makes this easy.
Here there problem with the trac (and other plugin systems I've seen)
approach:
You need to define something like:
|
| class IAuthPlugin(Interface): [...]
|
in your blog software.
Why? Any reason you can't define it in a separate package the
blog-software depends on, as well as your wiki?
And then of course, this is not really needed. In Python, behavior
counts, not type-information. So you can get away without any explicit
declared interface. You might chose to not do that, for aestetic
reasons, or better documentation. But you aren't forced.
diez
--
http://mail.python.org/mailman/listinfo/python-list
