Module interdependencies

Ken Seehof kseehof at neuralintegrator.com
Mon Sep 24 17:54:50 EDT 2001


> I have a problem with moduel interdependencies.
> I have a package Test and a package Formula (logic language).
> There is a module txtTest, and tkTest and both use TestFramework.
> Now I am testing Formula.engine with txtTest.
> The problem happens when I change TestFramework.
>
> import Test.txtTest as txtTest
> import formula.normal as normal
>
> txtTest.run(normal.NormalizeTest)
>
> ! bug detected in TestFramework
> ! TestFramework changed, bug fixed
>
> reload(txtTest)
>
> ! still get old bug
>
> import TestFramework
> reload(TestFramework)
> reload(txtTest)
>
> ! still seems to run with old TestFramework definition
>
> To get it right I have to exit the interpreter and restart it.
> There has to be a better way to do this.
> Any ideas?

The simplest approach is to run your app outside of the interpreter.  Just
make an icon (or an alias or whatever) that lanches your app.

If you really want to run from the interpreter, you should avoid using "from
... import", and watch for any side effects associated with TestFramework
(such as other modules copying things from TestFramework).  For example, if
another module derives a class from a class defined in TestFramework,
reloading TestFramework will not do any good, since the derived class is
based on the old version of TestFramework.

Here's another interdependecy hint:  Strange as it may look at first, there
is nothing wrong with importing a module when you need it, inside a function
instead of at the top of your file.  Many python programmers (myself
included) have used C++ extensively, so we've been programmed to believe
that imports (includes) belong at the top.  This will help detangle
interdependencies, and reduce the initial load time of your program.

- Ken






More information about the Python-list mailing list