On Sun, Jul 24, 2011 at 12:54 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Sun, Jul 24, 2011 at 3:05 PM, Eric Snow <ericsnowcurren...@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 | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
