New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sys.modules cannot be reassigned #62153
Comments
In Python 3.3 (I did not test with 3.4), sys.modules cannot be reassigned without breaking the import mechanism; while it works with Python <= 3.2. Here is how to reproduce the bug: progval@Andromede:/tmp$ mkdir test_imports
progval@Andromede:/tmp$ echo "from . import module" > test_imports/__init__.py
progval@Andromede:/tmp$ echo "print('foo')" > test_imports/module.py
progval@Andromede:/tmp$ python3.3
Python 3.3.1 (default, Apr 6 2013, 13:58:40)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules = dict(sys.modules)
>>> import test_imports
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "./test_imports/__init__.py", line 1, in <module>
from . import module
SystemError: Parent module 'test_imports' not loaded, cannot perform relative import
>>>
progval@Andromede:/tmp$ python3.2
Python 3.2.3 (default, May 6 2013, 01:46:35)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules = dict(sys.modules)
>>> import test_imports
foo
>>> |
I wouldn't call it a bug personally. The modules dictionary is used in all kinds of places in the interpreter; you can change the dictionary's contents, but not swap it with another one. It's just a pity that we can't forbid reassignment altogether. |
There is no good way to solve this. At the C level there interpreter struct has two key fields, sysdict and modules. The former is sys.__dict__ and the latter is sys.modules. But when you re-assign sys.modules you then break the assumption that sys.modules is the same dict as that contained in interp->modules. And this all goes out the window as the C code is expected to use interp->modules while the Python code in importlib only has access to sys.modules. The reason this used to "work" is your new dictionary was completely ignored and so we basically a no-op from the perspective of import (done in Python 2.7 but same result in any version up to Python 3.3):: >>> import sys
>>> original_modules = sys.modules
>>> new_modules = sys.modules.copy()
>>> sys.modules = new_modules
>>> import pkg
>>> 'pkg' in original_modules
True
>>> 'pkg' in new_modules
False What really needs to happen is that sys.modules needs to be documented as something that cannot be replaced. If you really want to update it cleanly then do I have updated the issue to be a documentation one and added Python 3.4 to the affected versions. |
"sys.modules How about adding at the end or to be slightly more explicit "However, replacing it or deleting critical entries may cause Python to fail." |
Sounds good to me. |
Documentation added for sys.modules |
New changeset 4f8160e45cb7 by Brett Cannon in branch '3.3': New changeset b60ae4ebf981 by Brett Cannon in branch 'default': |
Thanks for the patch, Yogesh, but I went with different wording that I came up with on the train the other day while offline. But you did remind me to update Misc/NEWS (which led to a discussion on python-committers), so thanks for that. |
You are most welcome Brett. I am just starting to contribute with this doc fix. Didn't think a small detail in it will generate such a long debate in the python-committers mailing list. Is there a plan in action for 'fixing' Misc/NEWS. I now realize that this change is too small to warrant an entry there, however, as someone new to the list, I simply followed http://docs.python.org/devguide/patch.html. Doing a make patchcheck warns about no changes to Misc/NEWS. IMHO it would be great if this tool can look at the files changed (or maybe at-least just the directory, or even, simply number of lines modified) and decide if an entry is required in Misc/News. Of-course this is from my perspective. I would like to get your view on this and help about the solution if possible. |
I think that is a reasonable suggestion for an enhancement to patchcheck (though I think Brett had a good reason to add a news entry in this particular case). You could open a new issue with that suggestion. On the other hand, patchcheck always warns about other stuff that it can't so easily realize aren't really needed, so it may not be considered a worthwhile enhancement. |
That sounds good. I will open up an issue (if not for anything else other than to get more eyes on this issue) |
For the record, bpo-12633 has some more discussion on this. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: