PCAP Modules and Packages Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use relative imports inside the package to avoid hardcoding the package name

  Why it's wrong here

  Relative imports such as `from . import helper` are implicitly tied to the current module's `__package__` and the file's exact position in the package hierarchy. If a module is moved, renamed, or the package is restructured, these imports silently resolve to a different target or fail with an opaque error. PEP 8 explicitly recommends absolute imports because they are more explicit and produce clearer error messages when something goes wrong. The notional benefit of avoiding a hardcoded top-level name is outweighed by the fragility and reduced readability of dot-relative references.

• ✗

  Keep all modules in a single package for simplicity

  Why it's wrong here

  Consolidating every module into one flat package may look simple at first, but it quickly leads to an unmanageable namespace, tangled circular imports, and a flat structure where unrelated components share the same level. Large applications need hierarchical subpackages that group related code, enable separate testing, and allow clear dependency boundaries. A single package also makes it harder to apply `__init__.py`-level re-exports or to evolve the design without introducing import cycles. The simplicity is therefore only superficial and does not scale with team size or codebase growth.

• ✗

  Avoid using __init__.py to keep packages lightweight

  Why it's wrong here

  While Python 3 supports namespace packages without `__init__.py`, regular packages still rely on `__init__.py` for initialization, controlling what is public via `__all__`, and eagerly importing convenience submodules. Avoiding it means you lose a central place to set package globals or document the package API, and you may unintentionally create namespace packages with different semantics. This 'lightweight' approach makes the package's interface implicit and harder to maintain, which is generally considered an anti-pattern for a large application. Best practice is to keep `__init__.py` even if it is empty.

• ✓

  Use absolute imports with the package name to prevent breakage when the package is moved

  Why this is correct

  Absolute imports that start with the full top-level package name (for example `from myapp.utils.helpers import parse`) make the dependency graph explicit and easy to reason about, even when a submodule is moved within the package. Because every import references the same root, the interpreter can detect a broken path immediately and give a clear `ModuleNotFoundError` instead of silently resolving to a different local module. This clarity reduces the risk of accidental name shadowing and aligns with PEP 8's recommendation that absolute imports are the more robust, readable choice for production code. Anchoring imports to the package name ensures that refactoring tools and static analyzers can follow the actual location of each name.