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.

• ✗

  Define __all__ as a function that returns the list of modules in '__init__.py'.

  Why it's wrong here

  The __all__ attribute is not a factory or callback; it must be a sequence of string names, such as a list or tuple. During a from utils import * statement, the import machinery reads __all__ and iterates over it to decide which names to bind. If you assign a function, Python will attempt to iterate over the function object and raise TypeError, because functions are not iterable in this context. There is also no mechanism for Python to invoke a function to lazily compute the public API.

• ✓

  Define __all__ = ['mod1', 'mod2'] in '__init__.py' of the 'utils' package.

  Why this is correct

  Placing __all__ = ['mod1', 'mod2'] in the package's __init__.py is the canonical way to declare the package's public interface. When from utils import * is executed, the __init__.py code runs first, and the import system reads the __all__ list from the package's namespace, importing only the listed submodules. This also aids static analysis tools and IDE autocomplete by making the intended exports explicit, and prevents unintended names from leaking out in wildcard imports.

• ✗

  Set the __all__ variable in the script that imports the package.

  Why it's wrong here

  The __all__ variable only takes effect when defined in the module or package that is the target of a star import; it is not a consumer-side setting. A script that simply assigns __all__ = [...] in its own global namespace creates an unrelated global variable and has no influence on the utils package's exports. Even assigning utils.__all__ after the package is imported does not retroactively change a completed from utils import * and is not the documented pattern, since the package itself should own this declaration.

• ✗

  Define __all__ as a list of module objects in the main module 'utils.py'.

  Why it's wrong here

  For a package, the correct location is __init__.py, not a separate module file called utils.py, because the package's namespace and __all__ live in __init__.py. In addition, __all__ must contain strings — the names of the submodules or attributes — not module objects. When from utils import * is processed, Python uses __all__ entries as attribute names to look up in the package dictionary; if you put module objects there, the star import would fail (or behave unexpectedly) because it expects name strings, and the API contract would be broken.

Go deeper

Related to this question