class / module introspection?

[bruno.desthuilliers at gmail.com]

On 2 avr, 18:03, Brian Munroe <brian.e.mun... at gmail.com> wrote:
> I'm struggling with an architectural problem and could use some
> advice.
>
> I'm writing an application that will gather statuses from disparate
> systems.  Because new systems show up all the time, I'm trying to
> design a plugin architecture that will allow people to contribute new
> backends by just dropping a package/module into a specific directory.
> The object methods in these backends will conform to a documented API
> that the main application will call.
>
> Currently I have something that looks like this:
>
> src/
>     backends/
>         system1/
>             __init__.py
>         system2/
>             __init__.py
>         ...
>
> Then from my application (main.py) I can simply call:
>
> from backends import system1
>
> be1 = system1.Backend()
> be1.getStatus()
>
> This would work great if I knew about system1 and system2 ahead of
> time, but that isn't the case.  Having to rewrite main.py every time a
> new backend module comes along is obviously a stupid idea too.  I've
> been thinking I need some kind of introspection, but I've been reading
> about it and a whole mess of design pattern stuff, so my head is
> swimming and I am totally unsure of what the best approach is.
>
> My guess is that I need to load all the backends at runtime

Anyway, almost everything happens at runtime in Python !-)

More seriously: the answer is in the doc.
http://www.python.org/doc/2.3.5/lib/built-in-funcs.html

read about the __import__ function, experiment in your interactive
python shell, and you should be done in a couple minutes.