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
Surprising name binding behavior of submodule imports needs documenting #68217
Comments
As described here: http://news.gmane.org/find-root.php?message_id=20150422115959.1ff2ee58%40limelight.wooz.org Importing a submodule binds the submodule's name in the parent module's namespace. This is surprising, but it seems intentional and it's relied upon by existing code, e.g. asyncio/init.py in the stdlib. It's also not documented afaict. It should be documented in the Language Reference's section on the import system. After a little more discussion on import-sig, I plan on doing that. |
From Guido: It's definitely intentional, and it's fundamental to the package import I guess another thing to realize is that the globals of __init__.py are I'm not surprised it's in the reference manual -- that hasn't been updated |
More rationale from the thread:
No, that must also have been intentional, because even when you use |
Guido describes the global invariant for *all* the forms of importing a submodule, including explicit relative imports:
But there *is* a reason. The submodule must still be an attribute of the parent package, because of the invariant that if you have sys.modules['foo'] and sys.modules['foo.bar'], the latter must appear as the 'bar' attribute of the former. This is an invariant of module loading, and (I feel I'm repeating myself) the form of import used does not affect loading. |
Here's some new text for the Language Reference. |
LGTM. You've covered all the key points and the example is good. |
Cool, thanks! I'll commit it and we can always clean it up/add to it later if needed. |
New changeset 3968e7a9614c by Barry Warsaw in branch '3.4': New changeset 351ad8c4f3a6 by Barry Warsaw in branch '3.4': New changeset 6295f207dfaa by Barry Warsaw in branch 'default': |
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: