Module gets garbage collected; its globals become None

["Martin v. Löwis"]

Steven Taschuk wrote:

> So much for *how* this occurs.  What I'm curious about is why --
> why do the dict's values have to be cleared when the module is
> collected?  Why not just let the dict, and hence its values, get
> collected in its turn?

Historically, this was there to break cycles between modules,
when there was no cyclic garbage collection.

> Is it, as a comment in moduleobject.c suggests, to "make the
> execution order of destructors for global objects a bit more
> predictable"?  

Also that. Shutdown is a really tricky thing in Python, and
any approach is likely "wrong" in some scenario. All modules
get cleared to release objects when then may invoke __del__.
By doing so, they may trigger additional invocation of code.

At some point, internal things get cleared. When that happens,
no further Python code should be executed, as the interpreter
is no longer operational. Therefore, it is desirable to run
all user-defined finalizers before that phase of shutdown
starts. This is achieved by clearing the modules.

> And if so, couldn't this equally as well be done by
> giving modules' dicts their own tp_dealloc, one which clears them
> in the desired order?

Not sure what you are suggesting here.

It may be that it is time to revise this approach for
Python 2.4, by completely eliminating it (and putting as much as 
possible on the shoulders of cyclic gc). I doubt anybody can
tell what precise consequences such a change would have, so
it would be good if somebody studied the shutdown behaviour
of some of the larger applications if the interpreter changes.

Regards,
Martin