Python Modules and Packages

A module is simply a .py file containing Python definitions and statements — its name is the filename without the .py. Importing it makes its functions, classes, and variables available under that module's namespace, which is the basic unit of code reuse and organization.

import math
print(math.sqrt(16))            # access via the module namespace

from math import sqrt, pi       # import specific names

Follow-ups interviewers raise:

• Modules aren't only .py files: built-in/C-extension modules (sys, math) and packages (directories) are also modules. dir(module) lists its contents.
• A module's top-level code runs once on first import, then the module object is cached in sys.modules — re-importing doesn't re-execute it.
• import x vs from x import y: the first keeps the namespace (x.y), the second binds names directly; avoid from x import *, which pollutes the namespace.
• if __name__ == "__main__": lets a file act as both an importable module and a runnable script — the guarded block only runs when the file is executed directly, not when imported.
• How imports are found: Python searches sys.path (current dir, PYTHONPATH, then standard locations).

A package is a directory of modules treated as a single importable namespace, letting you organize a large codebase into a hierarchy (mypkg.subpkg.module). You import from it with dotted paths:

from mypkg.utils import helper
import mypkg.subpkg.module

Follow-ups interviewers expect:

• __init__.py: a regular package is a directory containing an __init__.py file (which can be empty, or expose a curated public API). Its code runs when the package is first imported.
• Namespace packages (PEP 420, since 3.3) don't need __init__.py — they let one logical package span multiple directories, which is why an empty __init__.py is no longer strictly required. Use a regular package when you want a defined import-time API; a namespace package when splitting across locations.
• Relative vs absolute imports: within a package you can write from . import sibling or from .sub import thing; PEP 8 generally prefers absolute imports for clarity.
• Distribution vs import package: the thing you pip/uv install (the "distribution") can differ in name from the import name, and modern packaging is configured in pyproject.toml.
• dir(package) and package.__path__ help introspect what's inside.

A namespace is a mapping from names to objects — effectively a dictionary that tracks which identifier refers to which object. Namespaces keep names from different parts of a program from colliding: math.pi and numpy.pi coexist because each lives in its own module namespace.

Python maintains several kinds, resolved by the LEGB rule — the order in which a name is looked up:

• Local — names inside the current function.
• Enclosing — names in any outer (enclosing) function, the basis of closures.
• Global — names at the top level of the module.
• Built-in — names always available (len, print, range).

x = "global"
def outer():
    x = "enclosing"
    def inner():
        print(x)      # finds 'enclosing' via LEGB
    inner()

Follow-ups interviewers expect:

• global and nonlocal: by default assigning to a name creates a local; global x rebinds the module-level name, nonlocal x rebinds the nearest enclosing one. Forgetting this causes the classic UnboundLocalError.
• Namespaces have different lifetimes: the built-in namespace lasts the whole run, a module's lasts until the program ends, a function's is created on call and destroyed on return.
• globals(), locals(), and vars() let you inspect them, and dir() lists names in the current scope.

PYTHONPATH is an environment variable that adds extra directories to Python's module search path. When you import a module, Python looks through sys.path; entries in PYTHONPATH are inserted into that list (after the script's own directory but before the standard library locations), so modules in those directories become importable.

export PYTHONPATH=/home/me/mylibs:$PYTHONPATH
python app.py        # can now `import` modules under /home/me/mylibs

Follow-ups interviewers expect:

• PYTHONPATH vs sys.path: sys.path is the actual runtime list Python searches; PYTHONPATH is just one source that seeds it (alongside the current dir, stdlib, and site-packages). You can also mutate sys.path in code, though that's a code smell.
• It's generally a workaround, not best practice. In modern 2026 workflows you avoid fiddling with PYTHONPATH by using a proper package installed into a virtual environment — uv/pip install -e . with a pyproject.toml makes your code importable cleanly, with no env-var hacks.
• Common pitfall: a PYTHONPATH entry can shadow a stdlib or installed module (e.g. a local random.py), causing confusing import bugs.
• It's also the wrong tool for picking a Python version — that's what virtual environments and version managers are for.

dir() is a built-in introspection function. Called with an object, it returns a sorted list of that object's attributes and methods; called with no argument, it returns the names in the current local scope.

dir()              # names defined right here
dir(str)           # all attributes/methods of the str type
dir([])            # list methods: append, extend, pop, ...

It's most useful at the REPL or while debugging, to discover "what can I do with this object?" without leaving Python.

Follow-ups interviewers may add:

• What it actually returns: names including dunder methods (__len__, __iter__). Under the hood it consults the object's __dir__() method, which a class can customize.
• dir() vs help() vs vars(): dir() lists names; help(obj) shows documented signatures/docstrings; vars(obj) returns the object's __dict__ (its instance attributes only).
• Related introspection tools: type() for the class, isinstance() for type checks, getattr/hasattr to access names dynamically, and the inspect module for richer introspection (signatures, source).
• It's a discovery aid, not something you'd rely on in production logic — for stable APIs you'd reference documentation or type hints rather than scraping dir().

A practical question that's almost guaranteed for any applied role. A virtual environment is an isolated per-project Python with its own installed packages, so projects don't clash on dependency versions.

The traditional stack: python -m venv .venv + pip install + a requirements.txt. Activate with source .venv/bin/activate.

The 2026 best-practice answer interviewers increasingly expect: uv (a Rust-based tool from Astral) now consolidates pip, venv, virtualenv, pip-tools, and much of poetry into one fast tool, with a real lockfile (uv.lock) and pyproject.toml as the single source of truth:

uv venv            # create the environment
uv add requests    # add a dependency, update pyproject + lockfile
uv run app.py      # run inside the managed env
uv sync            # reproduce the locked environment exactly

Follow-ups: why lockfiles matter (reproducible builds), pyproject.toml vs the legacy setup.py/requirements.txt, never installing into the system Python, and that uv/pip plus pyproject.toml is the modern packaging direction (PEP 517/518/621). Poetry and Pipenv remain common in existing codebases.