Develop-test-debug cycle

[Tim Peters]

[Charl P. Botha]
> ...
> In anycase, I have a rather large software platform that reloads
> modules with classes all the time.  So, the platform itself keeps on
> running while I hack away at a new module; with every change I reload
> the module and my platform instantiates it AND I get to see the changes
> in action.  Test.  Modify.  Repeat.
>
> Maybe the complex/simple case classifier in my version of Python
> is buggy? ;)

Yes, and we're not going to fix it <wink>.

"The problem" is that modules are objects just like any other objects in
Python, and "import" does binding just like any other binding stmt.  When
module X does

import Y

X gains a module variable named "Y" bound to whatever module code was most
recently loaded for Y.  A subsequent reload(Y) *outside* of X can't change
the binding of X.Y -- within X, Y still refers to "the old" module object.
Ditto for things like "from Y import ClassA" inside X, of course -- no
matter what happens to Y, X.ClassA continues to refer to whatever Y.ClassA
mapped to at the time the import statement was executed.

There isn't a clear way to "fix this", in part because it's hard to come up
with a rigorous way to justify calling it "broken" to begin with:  the code
does what the Ref Man says it does, and that's just how objects and binding
statements work in Python.  In the same way, after doing

x = [1, 2, 3]
y = x

a later instance of

x = [3, 2, 1]

doesn't magically change the binding of y either.