The thing is, even though Python's import
statement is designed to look similar to Java's, they do completely different things under the hood. As you know, in Java an import
statement is really little more than a hint to the compiler. It basically sets up an alias for a fully qualified class name. For example, when you write
import java.util.Set;
it tells the compiler that throughout that file, when you write Set
, you mean java.util.Set
. And if you write s.add(o)
where s
is an object of type Set
, the compiler (or rather, linker) goes out and finds the add
method in Set.class
and puts in a reference to it.
But in Python,
import util.set
(that is a made-up module, by the way) does something completely different. See, in Python, packages and modules are not just names, they're actual objects, and when you write util.set
in your code, that instructs Python to access an object named util
and look for an attribute on it named set
. The job of Python's import
statement is to create that object and attribute. The way it works is that the interpreter looks for a file named util/__init__.py
, uses the code in it to define properties of an object, and binds that object to the name util
. Similarly, the code in util/set.py
is used to initialize an object which is bound to util.set
. There's a function called __import__
which takes care of all of this, and in fact the statement import util.set
is basically equivalent to
util = __import__('util.set')
The point is, when you import a Python module, what you get is an object corresponding to the top-level package, util
. In order to get access to util.set
you need to go through that, and that's why it seems like you need to use fully qualified names in Python.
There are ways to get around this, of course. Since all these things are objects, one simple approach is to just bind util.set
to a simpler name, i.e. after the import
statement, you can have
set = util.set
and from that point on you can just use set
where you otherwise would have written util.set
. (Of course this obscures the built-in set
class, so I don't recommend actually using the name set
.) Or, as mentioned in at least one other answer, you could write
from util import set
or
import util.set as set
This still imports the package util
with the module set
in it, but instead of creating a variable util
in the current scope, it creates a variable set
that refers to util.set
. Behind the scenes, this works kind of like
_util = __import__('util', fromlist='set')
set = _util.set
del _util
in the former case, or
_util = __import__('util.set')
set = _util.set
del _util
in the latter (although both ways do essentially the same thing). This form is semantically more like what Java's import
statement does: it defines an alias (set
) to something that would ordinarily only be accessible by a fully qualified name (util.set
).