[Python-Dev] Is this a bug?

[Nick Coghlan]

Josiah Carlson wrote:
> This is the case for Python 2.3, 2.4, and 2.5 beta.  prefixing the above
> two operations with:
>     sys.modules['_oldmain'] = sys.modules['__main__']
> 
> Is sufficient to prevent Python from tearing down everything after the
> sys.modules['__main__'] reassignment.  Not a big deal, but a sys.modules
> manipulation that has a gotcha.

Early versions of the PEP 338 implementation also ran into the problem of a 
module's globals getting cleared when the module itself goes away - that's why 
runpy makes sure to return a copy of the module's global namespace instead of 
the original.

The core of the problem in the atexit case seems to be the fact that holding 
on to a reference to a function from a module only holds a reference to the 
module's dict, rather than the module object itself.

If you kill the reference to the module from sys.modules, the module object 
goes away, and the dict gets cleared. However, any function objects being held 
elsewhere (e.g. in the atexit list, or as a result of a class being subclassed 
in a different module) still have a reference to the now defunct module 
namespace, and will misbehave when called later on if they attempt to access 
any global variables.

Are we really sure that explicitly clearing the module's globals when the 
module's refcount falls to zero solves more problems than it causes? Or is it 
primarily a legacy of the pre-cyclic GC days when it was absolutely essential 
to manually break the cycle between the module namespace and any functions it 
contained?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org