More on those Python import oddities
From the reddit discussion
and also the comments of my previous entry on
I learned that people both do '
import os.path' and then use
os.whatever without explicitly importing
os, and do '
and then just use os.path.whatever without explicitly importing
First off, I don't think that you should do either of these even if
(and when) they work, for
os or any other module. This is a stylistic
thing, but when doing imports I prefer to be explicit about what other
modules my code uses. Also, I don't like clever tricks like this because
they run a high risk of confusing people who read my code, and this
includes me in the future if I've forgotten this bit of arcane trivia by
Both of these clearly work for
os. But are they guaranteed to work in
general? The answer is half yes and half no.
As sort of discussed last time, '
x.whatever' is guaranteed to work because the semantics of useful
multi-level imports require it. '
import x.y' is pointless if you cannot
resolve x.y.whatever afterwards, and in order to do that you must have
x' in your namespace after the dust settles. So Python gives it
A more interesting question is whether '
import x; x.y.whatever' is
guaranteed to work. The short answer is no, although I suspect that it
often will for relatively small modules. First off, modules that are
implemented as single Python files (as with
os) have to make this
work; as discussed last time,
x.y must be defined
after x.py has finished executing as part of the import process, because
there is no other way for the interpreter to find the x.y module.
For modules that are implemented as directories (with submodules as
either files or subdirectories) there is no requirement that the
__init__.py import the
y submodule for you. The tradeoff
is that importing submodules automatically makes '
from x import
*' work as people expect, at the cost of loading potentially large
submodules that people are not going to use; the larger and less used
your set of submodules is, the more this matters. So you can sensibly
have a module that requires explicit imports of submodules, and indeed
there are modules in the Python standard library that work this way
xml is one example).
Now we come to a piece of
import trivia: importing a submodule will
actually modify the parent module's namespace. If you do
(in any variant) and
y is not defined in
x's namespace, Python adds
it for you. Once I thought about it, I realized that it had to work
this way if Python wanted to support submodules that had to be loaded by
hand, but I find it vaguely interesting that Python is willing to drop
things in another module's namespace for you as a result of stuff that
(This happens even if you do not get an explicit reference to
eg if you do '
import x.y as t'.)