How Do Imports Work in Python?

There are three forms, and the difference is which names end up in your namespace.

import math
from math import sqrt, pi
import math as m

print(math.floor(2.7))       # 2
print(sqrt(16))              # 4.0
print(m.ceil(2.1))           # 3
print(round(pi, 4))          # 3.1416

The plain import binds the module name itself, so you reach everything through math.floor and so on. The from import binds the individual names, so sqrt is available directly — which is convenient, but it loses the information about where the name came from and makes it easy to collide with a local variable of the same name.

The aliased import is the compromise: it binds a short name to the whole module, which keeps the origin of the name visible while avoiding a long prefix.

The guidance that comes out of this is to prefer plain import and qualify the names, particularly in library code. It makes the origin of every name obvious and it avoids surprising collisions. The from import form is fine for a handful of well-known names, and importing a module inside a function is a useful way to keep an expensive import out of the module's start-up path.

Importing a module is a four-step process. Python checks sys.modules first — if the module is already loaded, it is reused and nothing happens again. Otherwise the import machinery searches sys.path, which is a list of directories, for a matching file or package. It then creates a new module object, executes the module's code with a fresh namespace, and finally binds the result to the name you imported.

Two details make this efficient and correct. The first import of a module runs its code; every later import finds it in sys.modules and returns the same object, so modules are singletons by default. And the binding is not circular — if two modules import each other, the partially initialised module object is found in sys.modules and the import machinery handles it rather than looping forever.

A module is a single .py file. A package is a directory containing an __init__.py file, and it is treated as a namespace for submodules. Since Python 3.3 a directory without __init__.py is also importable as a namespace package, which is why many modern projects omit the file.

The search itself follows sys.path, and that order matters. The current directory usually comes first, which is why a file called random.py in your project shadows the standard library module of the same name — a genuinely confusing bug. The standard library modules that live inside the package, such as os.path inside os, are imported with a from os import path statement.

Every module object carries a few attributes that answer exactly that question.

import json
import sys

print(json.__name__)                    # json
print(json.__file__.endswith(".py"))     # True
print(json.__doc__.splitlines()[0])      # JSON (JavaScript Object Notation) encoder
print(sys.modules["json"] is json)     # True - modules are cached

__name__ gives the module's name as it was imported, __file__ gives the path of the source file, and __doc__ holds the module docstring — the first line of which is printed for the standard json module.

The last line is the interesting one. sys.modules is the cache the import machinery consults, and the identity check confirms that the json you imported is the very same object stored in it. That is why importing the same module twice is cheap and why module-level state is shared: a second import returns the existing object rather than creating a new one.

Two related tools are worth knowing. The pkgutil and importlib modules let you enumerate and import packages programmatically — importlib.import_module("package.module") takes a string, which is what you need when the module name is only known at runtime. And the standard library module inspect has a function called getmodule that finds the source file of an object, which is very handy in a debugger.