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.

• ✗

  from .shared.math_ops import calculate

  Why it's wrong here

  A single leading dot indicates a relative import that starts from the current package. This syntax is only valid inside a properly initialized package (where the module's __package__ attribute is set), so if the developer's script is executed directly as a top-level module, this raises ImportError: attempted relative import with no known parent package. Even if it did run inside a package, it would resolve to a shared package nested within the current package's parent, not the top-level shared package the developer intends. Since the goal is to import from the top-level shared package, this absolute-import scenario is incorrectly expressed as a relative import.

• ✗

  from ..shared.math_ops import calculate

  Why it's wrong here

  Two leading dots mean the import is relative to two levels above the current package, so Python searches for shared.math_ops by first moving up two package levels and then looking for a submodule named shared. This requires the current module to be at least two package levels deep and have a fully defined package hierarchy; a standalone script run directly will not meet this requirement and will raise an error. Even in a correctly nested package, this resolves to a shared module that is a sibling of the package two levels up, not the top-level shared package on sys.path. Thus it fails both syntactically and semantically for the developer's intended absolute import.

• ✓

  from shared.math_ops import calculate

  Why this is correct

  This is an absolute import: Python searches for the shared package by scanning the directories listed in sys.path, which normally includes the directory containing the script, the standard library, and site-packages. If shared is a top-level package in that path (e.g., a folder with an __init__.py in the project root or a namespace package), the import will succeed. This is the correct and recommended way to import from a top-level package because it is unambiguous and matches the developer's intent. The from ... import statement also directly binds the calculate function into the current namespace, making the call site simple and explicit.

• ✗

  import ..shared.math_ops

  Why it's wrong here

  The import statement does not support relative imports with leading dots; PEP 328 specifies that relative imports are only allowed in the from package import module form. As written, import ..shared.math_ops will raise a SyntaxError because the parser does not accept dots as the first token of a module name after the import keyword. The valid relative-form equivalent would be from ...shared.math_ops import something, but even that would require a package context. In this scenario the developer needs an absolute import, so the correct statement would be import shared.math_ops or, better, the from form shown in the correct answer.

Go deeper

Related to this question