[Python-Dev] is sys.modules not meant to be replaced?

[Nick Coghlan]

On Sun, Jul 24, 2011 at 3:05 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> Are there other objects in the interpreter state that are exposed in
> sys that would have the same problem?

Rebinding (rather than mutating) any global state in any module is
always dubious due to the potential for direct references to the
previous value. (This is a large part of the reason why imp.reload()
often doesn't work in practice)

sys.modules, sys.path, sys.argv, sys.stdout, et al are all subject to
that caveat. For mutable state, the onus is typically on the developer
performing the substitution to decide whether or not those
consequences are acceptable (usually, they're not, hence you get
idioms like "sys.path[:] = saved_copy" to revert sys.path to a saved
value). For immutable state (such as sys.stdout), where modification
in place isn't possible, the obligation often goes the other way, with
developers deliberately avoiding cached references in order to
correctly react to runtime changes.

sys.modules is by far the worst case though, since dropping modules
out of that cache is only safe for modules that correctly support
imp.reload(). This is not the case for any module that mutates other
global state (or is otherwise referenced from other modules), nor does
it work properly for extension modules.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia