[Python-Dev] is sys.modules not meant to be replaced? (original) (raw)
Eric Snow ericsnowcurrently at gmail.com
Sun Jul 24 07:05:24 CEST 2011
- Previous message: [Python-Dev] is sys.modules not meant to be replaced?
- Next message: [Python-Dev] is sys.modules not meant to be replaced?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Jul 23, 2011 at 10:55 PM, Benjamin Peterson <benjamin at python.org> wrote:
2011/7/23 Eric Snow <ericsnowcurrently at gmail.com>:
The documentation[1] doesn't say, but the implementation of the imp module makes me wonder if sys.modules was not meant to be replaceable. No doubt this has to do with its tie to the interpreter's modules dict. I ran into this doing "sys.modules = sys.modules.copy()" to protect the actual sys.modules dict during some import related test cases. If the modules I imported were extension modules it broke.
So, is sys.modules not meant to be open to re-binding? Not any more or less than other global mutable objects. You can expect other code to be holding on to old references.
But, isn't sys.modules a little different because other modules (at least the imp module) don't use it. From what I understand the interpreter object's modules dict (to which sys.modules is initially bound) is used directly instead. So rebinding sys.modules causes a disconnect. That's why I am wondering if sys.modules is not meant to be rebound.
Are there other objects in the interpreter state that are exposed in sys that would have the same problem?
-eric
-- Regards, Benjamin
- Previous message: [Python-Dev] is sys.modules not meant to be replaced?
- Next message: [Python-Dev] is sys.modules not meant to be replaced?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]