PCAP Modules and Packages Practice Test 2 — 15 Questions

Question 1

In module_b.py, the developer writes: from mypackage import module_a. When running a script that imports mypackage, an ImportError occurs. Which change should solve the issue?

Accepted Answer

Use from .. import module_a (relative import).. Python relative imports use leading dots: one dot means the current package, two dots mean the parent package. If module_b.py is in mypackage/module_b.py, the correct relative import for module_a in the same package is 'from . import module_a'. 'from .. import module_a' would look for module_a in the parent of mypackage, which is not correct for a top-level package. If module_b.py is in a subpackage, 'from .. import module_a' could be appropriate. Since the stem does not provide the directory structure, answer A cannot be confirmed as correct.

Answer

Add 'module_a' to __all__ in mypackage/__init__.py.

Answer

Move module_b.py to the mypackage directory.

Answer

Use import mypackage.module_a instead.

Question 2

Two modules, 'module_a' and 'module_b', import each other. When 'module_a' is imported first, it tries to import 'module_b', which in turn tries to import 'module_a' again, causing a circular import error. Which of the following is the most effective strategy to resolve this circular dependency?

Accepted Answer

Move the shared code into a third module that both can import.. Moving shared code into a third module breaks the cycle because both module_a and module_b then depend on a common module rather than on each other. This is the standard architectural fix for circular imports: extract the mutually-needed symbols into a separate module that neither of the original two imports back. It eliminates the cycle at the dependency-graph level rather than working around it at runtime.

Answer

Place all code in a single module.

Answer

Use relative imports instead of absolute imports.

Answer

Use the import statement inside function definitions to defer imports.

Question 3

A package 'shapes' has an __init__.py file. Which statement must be included in the __init__.py file to allow the syntax 'from shapes import *' to import all submodules 'circle', 'square', and 'triangle'?

Accepted Answer

__all__ = ['circle', 'square', 'triangle'] and import each submodule. A wildcard import from a package imports all non-underscore names in the package namespace when __all__ is not defined. Importing each submodule in __init__.py places those names in the package namespace, so 'from shapes import *' will import them. Defining __all__ also works because Python imports the listed submodules. Thus options B, C, and D all satisfy the requirement.

Answer

Set __all__ to an empty list

Question 4

Which TWO of the following are valid ways to import a module 'math' in Python?

Accepted Answer

from math import *. The correct answers are C and E. Option C uses 'from math import *' which imports all names from the math module. Option E uses 'import math' which imports the entire module. Option A ('import Math') is incorrect because Python is case-sensitive and the module name must be lowercase. Option B ('import math,') is invalid due to the trailing comma. Option D ('from math import') is incomplete as it lacks the names to import.

Answer

import Math

Answer

import math,

Answer

from math import

Question 5

Which THREE of the following are recommended techniques to avoid circular imports in Python?

Accepted Answer

Restructure the code to move shared functionality into a separate module.. Option C is correct because circular imports arise when two modules mutually depend on each other at module load time; extracting the shared functionality into a third, dependency-free module breaks the cycle so each module imports only from that neutral module. Option D is correct because deferring the import statement into the body of a function or method means the module is only loaded when that code actually executes, by which point the other module has finished initializing, avoiding the partially-initialized-module problem. Option E is correct because absolute imports (e.g., 'from package.module import name') make the dependency graph explicit and unambiguous, which helps developers detect and refactor cycles that relative imports can obscure. Option A is not recommended because manually inspecting sys.modules is a fragile runtime workaround that does not remove the underlying dependency cycle. Option B is not recommended because __all__ only controls which names are exported by 'from module import *'; it has no effect on when or whether a module is imported, so it cannot prevent circular imports.

Answer

Manually check sys.modules before importing.

Answer

Use the __all__ variable to control what is exported.

Question 6

Refer to the exhibit. Which import statement in app.py will successfully import and use the greet function from helpers.py?

Accepted Answer

from .utils.helpers import greet. The package structure shown in the exhibit places app.py inside a package with utils as a subpackage. The relative import `from .utils.helpers import greet` correctly resolves `utils` relative to the current package. Option A fails because it does not bind the `greet` name. Option B fails because `utils` is not a top-level package in the exhibit. Option D fails because it uses `my_package` as the top-level package name, which is not the actual package name shown in the exhibit.

Answer

import utils.helpers; then greet()

Answer

from utils.helpers import greet

Answer

from my_package.utils.helpers import greet

Question 7

Which THREE factors influence Python's module search path (sys.path)?

Accepted Answer

The site-packages directory where pip installs packages. Option C is correct because site-packages is added to sys.path by the site module during interpreter startup, which is exactly where pip installs third-party packages so they can be imported. Option D is correct because when running a script, Python prepends the directory containing that script (sys.path[0]) to the search path, allowing sibling modules to be imported. Option E is correct because the PYTHONPATH environment variable is read at startup and its directories are inserted into sys.path, letting users extend the module search path. Option A is not correct because HOME is not consulted when constructing sys.path; it is used by other tools (e.g., pip config, virtualenv locations) but does not itself add entries. Option B is not correct because the current working directory is only added to sys.path in specific cases such as interactive mode or python -c, not as a general runtime factor for script execution.

Answer

The HOME environment variable

Answer

The current working directory at runtime

Question 8

You are a Python developer working on a project with the following structure:

myapp/
    __init__.py
    main.py
    modules/
        __init__.py
        utils.py
        helpers.py

The file main.py contains:

from modules import utils
from modules import helpers

utils.some_function()
helpers.another_function()

When you run main.py, you get an ImportError: No module named 'modules'. However, the modules directory exists and both __init__.py files are present. The directory myapp is not installed as a package; you are running main.py directly from the myapp directory. What is the most likely cause and how should you fix it?

Accepted Answer

Move main.py to the parent directory of myapp and use 'from myapp.modules import utils' or run with 'python -m myapp.main' from the parent.. When running main.py directly, Python adds the directory containing main.py (myapp) to sys.path, not its parent. Since 'modules' is a subdirectory of myapp, Python cannot find it as a top-level module. Moving main.py to the parent directory or using the -m flag (which sets the working directory as the script's location) allows 'from myapp.modules import utils' to resolve correctly, as myapp becomes a package.

Answer

Add the parent directory of myapp to sys.path at the beginning of main.py.

Answer

Add an __all__ variable in modules/__init__.py to explicitly export the submodules.

Answer

Rename modules/__init__.py to something else.

Question 9

A team maintains a library 'utils' with multiple modules. They want to expose a clean public API so that users can do `from utils import helper`. However, they also have internal modules that should not be accessible directly. Which approach best achieves this?

Accepted Answer

In utils/__init__.py, set __all__ = ['helper'] and rename internal modules with a leading underscore (e.g., _internal).. Using `__all__` in `__init__.py` explicitly controls what is exported when a user writes `from utils import *`, and renaming internal modules with a leading underscore (e.g., `_internal`) is a Python convention that signals those modules are private and not part of the public API. This combination allows `from utils import helper` to work while discouraging direct access to internal modules; note that Python does not enforce access restrictions, so these are conventions rather than hard barriers.

Answer

Use a single file named 'utils.py' and split functions into classes with private methods.

Answer

Remove all __init__.py files and rely on the module search path.

Answer

Name internal modules starting with 'import' to prevent from import *.

Question 10

Which TWO statements about the __init__.py file in a Python package are true?

Accepted Answer

It can be used to define the __all__ variable for package exports.. Option B is correct because __init__.py can define the __all__ variable, which controls what names are exported when using 'from package import *'. Option C is correct because any Python code placed in __init__.py runs when the package is first imported, allowing initialization logic, variable definitions, or side effects. Option D is correct because Python's import system specifically recognizes the filename __init__.py to mark a directory as a regular package (namespace packages being the exception that lack it). Option A is wrong because __init__.py may be completely empty; no import statement is required. Option E is wrong because __init__.py executes only once when the package is initially imported, not each time a submodule is imported.

Answer

The __init__.py file must contain at least one import statement.

Answer

It is executed every time a submodule is imported.

Question 11

You are working on a Python project that uses multiple third-party packages. One of your scripts imports 'requests' and 'numpy'. You notice that when you run your script, it uses the system-wide installed versions, but you want to use versions installed in a virtual environment. You have already activated the virtual environment using `source venv/bin/activate`, and `which python` points to the virtual environment's Python. However, when you import 'requests', it still uses the global version. What is the most likely reason?

Accepted Answer

The PYTHONPATH environment variable is set to the global site-packages.. When PYTHONPATH includes the global site-packages directory, those paths are inserted at the beginning of sys.path, ahead of the virtual environment's site-packages. Therefore, even with the virtual environment activated and the correct Python interpreter, the import system finds the global package first and loads it instead of the venv version. The --system-site-packages flag alone does not place global packages before venv packages; it appends them after.

Answer

The virtual environment's site-packages directory is not first in sys.path because the system site-packages are still included due to the --system-site-packages option or a misconfiguration.

Answer

The packages are not installed in the virtual environment; they are only listed in pip list erroneously.

Answer

The script is being run with the system Python instead of the virtual environment's Python.

Question 12

Your team is developing a large application with many packages. To avoid name conflicts, you decide to use namespace packages. You have two directories: /team/common/ and /team/analytics/. Both contain an __init__.py file. You want to create a namespace package 'team' that combines these two directories. You create a directory /team/ with no __init__.py. You then set PYTHONPATH to /team/common/ and /team/analytics/ (actually, you set it to the parent directories). But when you try to `from team.common import something`, you get ModuleNotFoundError. What is the most likely reason?

Accepted Answer

The PYTHONPATH should point to the parent directory of 'team', not to the subdirectories directly.. For namespace packages to work, PYTHONPATH must point to the parent directory of the 'team' namespace package, not to the subdirectories 'common' and 'analytics' directly, and not to the 'team' directory itself. When PYTHONPATH includes '/team/common/' and '/team/analytics/', Python treats each as a separate top-level package, so 'from team.common import something' fails because 'team' is not found as a package. The correct setup is to set PYTHONPATH to the directory that contains the 'team' directory (e.g., the parent of /team), allowing Python to discover 'team' as a namespace package and then locate 'common' and 'analytics' as sub-packages.

Answer

The presence of __init__.py in 'common' and 'analytics' prevents them from being part of a namespace package.

Answer

The namespace package requires an __init__.py in the parent directory as well.

Answer

The sys.path must also include the 'team' directory itself.

Question 13

A team is developing a large application that consists of multiple components, each housed in separate directories. They want to organize these components under a common namespace package called 'app'. The directory structure is as follows:

/opt/project/
├── components/
│   ├── auth/         (contains __init__.py and modules)
│   └── billing/      (contains __init__.py and modules)
├── main.py
└── another_location/
    └── reports/      (contains __init__.py and modules)

The team wants to allow all these components to be imported as subpackages of 'app', e.g., 'import app.auth', 'import app.billing', 'import app.reports'. They have ensured that none of the directories named 'app' exist; instead, they plan to use namespace packages. They create a directory '/opt/project/app/' with an __init__.py file, and move the auth and billing directories under it. However, the reports directory must remain at '/opt/project/another_location/reports/', but they want it to be accessible as 'app.reports'. They attempt to achieve this by adding '/opt/project/another_location/' to the sys.path. When they run main.py, they get an ImportError: No module named 'app.reports'. The auth and billing modules work fine. What is the most likely issue and the correct fix?

Accepted Answer

The reports package needs to be moved under the app directory physically.. For 'app.reports' to be importable, the reports directory must reside inside an 'app' directory on one of the sys.path entries. Adding '/opt/project/another_location/' to sys.path makes a top-level 'reports' package importable, not 'app.reports'. The presence of __init__.py in the app directory is irrelevant here; even if removed, Python cannot find reports as a subpackage because there is no 'app' directory in another_location. The necessary fix is to physically move the reports package under the app directory (or create an app directory in another_location and place reports inside it, then remove __init__.py for namespace merging).

Answer

The sys.path modification is not persistent; they need to set the PYTHONPATH environment variable.

Answer

The reports directory has an __init__.py file, which conflicts with the namespace package.

Answer

The app directory has an __init__.py file, which prevents it from being a namespace package. Remove the __init__.py from the app directory.

Question 14

A developer is creating a package named 'inventory' that will be used by other applications. The package directory contains an __init__.py file and several modules. The developer wants to control which names are imported when a user writes 'from inventory import *'. Which TWO of the following statements about __all__ in the package's __init__.py are correct? (Choose two.)

Accepted Answer

__all__ must be a list of strings, where each string is a name defined in the package's __init__.py or a submodule name.. The two correct statements are that __all__ must be a list of strings naming attributes in the package, and that without __all__, a star import brings in all non-underscore names including any submodules already imported in __init__.py. These reflect the actual behavior of the import system. The other options misstate the override effect, the need for submodule imports, and the required type of __all__.

Answer

If __all__ is defined, 'from inventory import *' will import all names in __all__ and also all other names that do not start with an underscore.

Answer

__all__ can include names of submodules that have not been imported in __init__.py, and Python will automatically import them when 'from inventory import *' is executed.

Answer

__all__ must be a tuple, not a list, because tuples are immutable and prevent accidental modification of the import list.

Question 15

A developer is working on a project that requires the use of a third-party package hosted on a private repository. The developer wants to ensure that the package can be imported without specifying the full repository URL each time. Which approach should be taken?

Accepted Answer

Configure the repository URL in pip's configuration file or in requirements.txt.. Configuring the repository URL in pip's configuration file (e.g., `pip.conf`, `pip.ini`, or `~/.config/pip/pip.conf`) or in `requirements.txt` using the `--index-url` or `--extra-index-url` option allows pip to resolve the package from the private repository automatically. This approach ensures that the package can be installed and imported without manually specifying the full URL each time, as pip will use the configured index to locate and download the package.

Answer

Append the repository path to sys.path in the script.

Answer

Place the package files in the site-packages directory manually.

Answer

Use os.system to run a pip install command from within the script.