From the import system documentation:
When a submodule is loaded using any mechanism (e.g.
importlib
APIs,
theimport
orimport-from
statements, or built-in__import__()
)
a binding is placed in the parent module’s namespace to the submodule
object. For example, if packagespam
has a submodulefoo
, after
importingspam.foo
,spam
will have an attributefoo
which is
bound to the submodule. Let’s say you have the following directory
structure:spam/ __init__.py foo.py bar.py
and
spam/__init__.py
has the following lines in it:from .foo import Foo from .bar import Bar
then executing the following puts a name binding to
foo
andbar
in
thespam
module:>>> import spam >>> spam.foo <module 'spam.foo' from '/tmp/imports/spam/foo.py'> >>> spam.bar <module 'spam.bar' from '/tmp/imports/spam/bar.py'>
Given Python’s familiar name binding rules this might seem surprising,
but it’s actually a fundamental feature of the import system. The
invariant holding is that if you havesys.modules['spam']
and
sys.modules['spam.foo']
(as you would after the above import), the
latter must appear as thefoo
attribute of the former.
If you do from testapp.api.utils import x
, the import statement will not load utils
into the local namespace. However, the import machinery will load utils
into the testapp.api
namespace, to make further imports work right. It just happens that in your case, testapp.api
is also the local namespace, so you’re getting a surprise.