On 4/12/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Tim Peters quoted Guido: > > > - when reload() is used on an extension > > > This is trickier: I guess reload should invoke the finalize function, > > discard the memory for the state, and then invoke the initialize > > function again, which will allocate a new state block. > > Actually, no, reload() has to remove the module from sys.modules and load it > anew. The reason for this is that any instances of types defined in the > module can still live, after the reload, and they would still refer to their > old-module-object-referring types. (And, as you said, this is a reason to > keep the 'state' in module objects.)
Maybe I'm misunderstanding, but the *identity* of the object ought to be retained across reload(). Consider two modules A and B each of which imports C. Now B says reload(C). Then A's reference to C should be updated automatically (but of course all instances of classes defined in C have references to the old class object, not the new one). Come to think of it, B's reference to C should also be updated automatically. And by "updated automatically" I don't mean that somehow the reference is patched (which would be very fragile -- there could be any number of aliases) but that the old module object continues to work. I don't care about preserving the old module's dict -- although there are some Python modules that care about preserving contents; I don't know if that feature should be extended to C extensions though. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
