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

[Eric Snow]

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

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
>