[Python-3000] Draft PEP: Module Initialization and finalization

Guido van Rossum guido at python.org
Thu Apr 13 09:48:02 CEST 2006


On 4/12/06, Thomas Wouters <thomas at python.org> wrote:
>
> On 4/12/06, "Martin v. Löwis" <martin at v.loewis.de> 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/)


More information about the Python-3000 mailing list