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.

• ✗

  import bar

  Why it's wrong here

  The statement `import bar` tells Python to search `sys.path` for a top-level module named `bar`, not for the submodule `pkg.bar`. If an unrelated `bar` module happens to exist on the path, that one gets imported, leaving the intended `foo` function inaccessible. If no such top-level module exists, the import fails with `ModuleNotFoundError`; either way, it never loads `pkg.bar`.

• ✓

  from pkg.bar import foo

  Why this is correct

  This is the canonical absolute import: the full module path `pkg.bar` is resolved, the submodule is loaded, and the name `foo` (the function object) is bound directly into the current namespace. After execution, you can call `foo()` without any package or module qualifier. It is explicit, unambiguous, and does not depend on any earlier side-effect imports.

• ✗

  import pkg; pkg.bar.foo

  Why it's wrong here

  Executing `import pkg` loads only the top-level package and runs its `__init__.py`; it does not by itself load the submodule `bar`. The subsequent expression `pkg.bar.foo` therefore raises `AttributeError` unless `pkg.bar` was already imported incidentally elsewhere (for example, inside `__init__.py`). This approach is fragile because it relies on package initialization side effects rather than on explicitly requesting the submodule. Even if it appears to work in one context, it may break when the package's import behavior changes.

• ✓

  from pkg import bar; bar.foo

  Why this is correct

  The form `from pkg import bar` explicitly asks the package for its submodule `bar`, which triggers loading of `pkg.bar` and binds the module object to the local name `bar`. After that, `bar.foo` accesses the function through that module object, which is valid because `bar` is now a loaded module. This is a correct alternative to `from pkg.bar import foo`, though it keeps `foo` inside the `bar` namespace instead of importing it directly.

• ✗

  import pkg.bar.foo

  Why it's wrong here

  The `import` statement only supports loading modules, not individual functions or other objects, when used in the dotted form `import a.b.c`. In `import pkg.bar.foo`, Python tries to interpret `foo` as a module path segment, but `foo` is a function inside `bar`, so import resolution fails with `ModuleNotFoundError` (or `ImportError` depending on the version). To import a function, you must use the `from` form: `from pkg.bar import foo`.

Go deeper

Related to this question