[Python-Dev] is sys.modules not meant to be replaced? (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Mon Jul 25 06:50:47 CEST 2011

On Sun, Jul 24, 2011 at 12:54 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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[:] = savedcopy" 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.

I agree with what you are saying wholeheartedly, but still think there is something fishy with the way that sys.modules works. I'll take it from here to a tracker issue though. :)

-eric

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

More information about the Python-Dev mailing list