Repository navigation
from module import function creates package reference to the module #71730
Description
Activity
mnijland commented
on Jul 17, 2016 mnijlandmannequinMannequinAuthorHello,
I've found an issue in python 2.7 and 3.4 and I don't if this is a bug or a feature that acts strange to me.
The import of a module or method from a module creates a reference in the package to that module only the first time, which could lead to unexpected behavior.
Description:
In following code there's one line marked with 'this line fixes the code to what I expected'- Without that line package.a.test() results in 'from module a'
- With the line package.a.test() results in 'from module b'
Situation 1 is unexpected because I did not create the reference to 'module a', python did that with the statement 'from package.a import test' and this will happen from any place in the code that loads 'module a' for the first time. The documentation says that this reference will not be created.
Kind regards,
Marc
# FILES USED
# test.py
# package
# __init__.py
# a.py
# b.py
# ---------------------
# Content of a.py:def test(): print('from module a')
# ---------------------
# Content of a.py:def test(): print('from module b')
# ---------------------
# Content of __init__.py#import a # <--- this line fixes the code to what I expected import b as a from a import test
# ---------------------
# Content of test.pyimport package print(dir(package)) package.a.test()
I'm not at a computer where I can verify what you're seeing, Marc,but I should mention that at least for Python 3 your imports are wrong as you should be doing relative imports, e.g.
from . import b as a, otherwise the imports won't work unless you're accidentally executing Python from within the directory of the package.The same example can be constructed for python3 by modifying the imports.
I think what is happening here is that if a has not yet been imported, then when 'from .a import test' is done, the import machinery loads a and then defines 'a' in the local namespace, overriding the previous 'import package.b as a'. On the other hand, if a has already been imported, the import machinery finds 'a' in sys.modules and skips the import-and-set-name-in-local-namespace step.
IMO the bug is that 'a' gets set at all when 'from a import test' is done, but the fact that it does so has a long history.
So the problem is that you doing
from .a import testand notfrom . import a; test = a.test. Whenever you dofrom X import Y, import actually imports X. Since X wasn't in sys.modules, it performs a proper import which means it sets the attribute on the package accordingly. But had Y been what you were after, then import simply looks for the Y attribute on the package instead of doing a full import.IOW everything is working as expected (and I still wish people weren't allowed to import objects out of modules directly).
Note that conceptually this is closely related to bpo-27515. In both cases the conceptual problem (the thing that trips up user expectations) is that what import does to the namespaces differs depending on whether the base module exists in sys.modules or not. I don't know that there is a fix, but it is certainly an inconsistency that causes mental hiccoughs.
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: