Why does `import xml` leave `xml.etree` an AttributeError while `import xml.etree` works?

## What the import statement actually does `import a.b.c` is not one operation. The import system walks the dotted name left to right and imports each prefix in turn: `a`, then `a.b`, then `a.b.c`. For each step it checks `sys.modules` for the full dotted key, and on a miss it finds, loads and executes that module. Two bindings then happen for each child: 1. the module object is stored in `sys.modules["a.b"]`, and 2. it is **set as an attribute named `b` on the parent module object `a`**. That second binding is the one candidates forget, and it is what makes `a.b` work as an expression afterwards. Note also what the statement binds locally: `import a.b.c` binds only the top-level name `a` in the importing namespace — you reach `c` by attribute traversal. `import a.b.c as name` binds only `name`. ## Why a bare parent import is not enough `import xml` runs step one and stops. Nothing has created `xml.etree`, so attribute lookup on the `xml` module object raises `AttributeError: module 'xml' has no attribute 'etree'`. A package's `__path__` tells the import system where its submodules *live*; it does not import them. Eager loading would mean importing a package always dragged in every module beneath it, which for a large package is exactly the cost nobody wants. There are two legitimate ways `pkg.sub` becomes usable: the package's own `__init__.py` imports the submodule (making it part of what the package offers), or the consumer imports it explicitly with `import pkg.sub` or `from pkg import sub`. ## from-import is subtly different `from pkg import name` first imports `pkg`, then looks for the attribute `name` on it. If that lookup fails, the import system tries to import `pkg.name` as a submodule and looks again; only if that also fails does it raise `ImportError`. So `from pkg import sub` works on a submodule that no one has imported, whereas `import pkg` followed by `pkg.sub` does not. This is also why a from-import failure message so often reads "cannot import name" — the attribute was missing and no submodule of that name existed either. ## The action-at-a-distance trap Because the child-on-parent attribute binding is stored on a module object shared by the whole process, it is permanent and global. Suppose a scheduled payment-reconciliation job has a module that writes `xml.etree.ElementTree.fromstring(...)` after importing only `xml`. It works in production, because some other module imported earlier in start-up happened to pull in `xml.etree.ElementTree`. It then fails in a unit test that imports the module alone, or on the day someone deletes that unrelated import, or when the entry point changes and the import order shifts. The failure is an `AttributeError` in code that has not been touched for a year, which is why it costs so much to diagnose: the module that broke is not the module that changed. The same shape bites under `multiprocessing` with a `spawn` or `forkserver` start method, where the child process re-imports the entry module from scratch and the convenient import ordering of the parent process does not exist. ## The rule that removes the class of bug Import what you use, by its own name, in the module that uses it: `import xml.etree.ElementTree` or `from xml.etree import ElementTree`. Never rely on a parent package exposing a submodule that its `__init__.py` does not import, and never rely on a third module having imported something first. A static checker will flag an undefined name but cannot see through an attribute chain rooted in a real, imported parent package — which is precisely why this bug survives review. ## The special case people over-generalize `import os` does give you `os.path`, and that misleads. `os` is a hand-written special case: its body selects the right path module for the platform, binds it as `os.path`, and also registers it in `sys.modules` so `import os.path` works. That is a module doing the work explicitly in its own body, not a general rule of the import system. Treat any package that exposes its submodules as having chosen to import them in `__init__.py`, and do not assume the next package made the same choice.