PCAP Modules and Packages Practice Test 7 — 15 Questions

Question 1

A company has a shared internal library stored in a Git repository. Developers need to use this library in multiple projects without copying the code. Which approach is the most Pythonic and maintainable?

Accepted Answer

Package the library as a proper Python package and install it via pip in each project's virtual environment.. Option C is correct because packaging the library as a proper Python package and installing it via pip in each project's virtual environment follows the Python packaging standard (PEP 517/518) and the principle of explicit dependency management. This approach ensures versioning, isolation, and easy updates without modifying sys.path or relying on fragile filesystem links, making it the most maintainable and Pythonic solution.

Answer

Add the library's directory to sys.path in each project's main script.

Answer

Create a symbolic link to the library's directory inside each project.

Answer

Copy the library source code into each project's directory.

Question 2

A developer wants to distribute a package that contains both Python code and data files (e.g., images, configs). Which file is used to specify dependencies and metadata for the package?

Accepted Answer

setup.py. Option B is correct because setup.py is the traditional script for packaging, defining dependencies, metadata, and data files. Option A is wrong because __init__.py initializes packages but does not define dependencies. Option C is wrong because requirements.txt lists dependencies for pip but is not part of the built package metadata. Option D is wrong because MANIFEST.in specifies additional files to include in the source distribution, but not dependencies.

Answer

MANIFEST.in

Answer

__init__.py

Answer

requirements.txt

Question 3

A package 'pkg' is installed as an egg-link in development mode. Inside the package, there is a module 'submod.py' that uses relative imports. When a developer modifies 'submod.py', they find that changes are not always reflected on import. What is the most likely reason?

Accepted Answer

Python's module caching in sys.modules prevents re-loading the modified source.. Option C is correct because Python caches imported modules in `sys.modules`. When a module is imported, Python stores the module object in `sys.modules` and subsequent imports retrieve it from this cache without re-executing the module's code. Modifying the source file of `submod.py` does not automatically invalidate this cache, so the changes are not reflected unless the module is explicitly reloaded (e.g., with `importlib.reload()`) or the interpreter is restarted.

Answer

The sys.path is altered by the egg-link, causing a different module to be loaded.

Answer

Relative imports are cached in the __init__.py file.

Answer

The __pycache__ directory is not cleared automatically.

Question 4

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

Accepted Answer

It can define the __all__ list to control what is exported with 'from package import *'.. Option D is correct because the `__all__` list in `__init__.py` explicitly defines the public API of a package, controlling which names are exported when a client uses `from package import *`. This is a standard Python mechanism to prevent unintended internal modules from being exposed.

Answer

It must contain at least one import statement to be valid.

Answer

It is mandatory for all packages, including namespace packages.

Answer

It prevents submodules from being imported directly.

Question 5

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 the site-packages directory is automatically included in sys.path by the site module during Python's initialization. This directory is the default location where pip installs third-party packages, making them importable without manual path manipulation.

Answer

The HOME environment variable

Answer

The current working directory at runtime

Question 6

Which TWO methods are valid ways to import a function named 'foo' from a module 'bar' that is part of a package 'pkg'?

Accepted Answer

from pkg.bar import foo. Option B is correct because the 'from pkg.bar import foo' syntax directly imports the 'foo' function from the 'bar' submodule within the 'pkg' package, making 'foo' available in the current namespace. Option D is also correct because it first imports the 'bar' module from 'pkg' using 'from pkg import bar', then accesses 'foo' as an attribute of 'bar' (bar.foo), which is a valid two-step approach.

Answer

import bar

Answer

import pkg; pkg.bar.foo

Answer

import pkg.bar.foo

Question 7

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.. Option A is correct because 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 8

You are a DevOps engineer managing a Python application that consists of multiple microservices. One microservice, 'data_processor', imports a shared library 'common_lib' which is also used by other microservices. The shared library is developed in a separate repository and is installed via pip in each microservice's virtual environment as an editable package (pip install -e). Recently, you updated 'common_lib' with new functions, but when you redeploy 'data_processor' (by restarting the container), the new functions are not available; the old version is still used. The container uses a Docker image built from a requirements file that specifies 'common_lib' from a Git repository. You verify that the Git commit hash in the requirements file points to the latest version. What is the most likely cause and what is the correct course of action?

Accepted Answer

Update the commit hash or use a version tag that points to the latest, and rebuild the Docker image without using cache (--no-cache).. When a Docker image is built, pip installs the package from the Git repository at the commit hash specified in the requirements file. Even if the requirements file points to the latest commit, Docker's layer caching may reuse a previously built layer that contains the old version of the package. Rebuilding the image with --no-cache forces Docker to re-execute the pip install step, fetching the latest code from Git and installing the updated common_lib. Simply restarting the container does not rebuild the image, so the old installed package persists.

Answer

Add the common_lib source directory to sys.path in the microservice code.

Answer

Rename the package in the requirements file to force a fresh install.

Answer

Change the Python interpreter to a different version.

Question 9

You are developing a package 'analytics' that contains subpackages 'stats' and 'ml'. The __init__.py of 'analytics' imports a function 'normalize' from 'analytics.stats'. When a user runs `import analytics`, they get an ImportError. Which change ensures the package imports correctly?

Accepted Answer

Change the import in analytics/__init__.py to: from .stats import normalize. Option C is correct because it uses an explicit relative import (`from .stats import normalize`), which is the proper way to import from a subpackage within a package. Absolute imports like `from analytics.stats import normalize` can fail if the package's parent directory is not in `sys.path`, which is common when running scripts directly. Relative imports resolve correctly based on the package structure, ensuring the import works regardless of how the package is invoked.

Answer

Change the import to: from stats import normalize

Answer

Add sys.path.append('.') before the import in __init__.py

Answer

Move the import statement to the stats/__init__.py file

Question 10

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).. Option B is correct because 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 preventing direct access to internal modules, as Python's import system respects the underscore convention and `__all__` restricts wildcard imports.

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 11

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 the `__init__.py` file can define the `__all__` variable, which is a list of module names that will be exported when a client uses `from package import *`. This controls the public API of the package by specifying which submodules or names are accessible via wildcard imports.

Answer

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

Answer

It must be named exactly __init__.py, with no other possible names.

Answer

It is executed every time a submodule is imported.

Question 12

Consider the following directory structure:
project/
  main.py
  pkg/
    __init__.py
    mod1.py
    subpkg/
      __init__.py
      mod2.py
From main.py, you write: from pkg.subpkg import mod2
Which THREE of the following are true regarding relative imports?

Accepted Answer

Relative imports only work when the importing module is part of a package.. Option A is correct because relative imports (using dot notation like `..` or `.`) are only valid when the importing module is itself part of a package. This is because relative imports rely on the `__package__` attribute to resolve the import path; if the module is not inside a package (e.g., a top-level script), `__package__` is `None` or empty, and relative imports will raise an `ImportError`.

Answer

In main.py, you can use `from . import pkg` to import pkg.

Answer

A directory must contain an __init__.py file to be a package for relative imports to function.

Question 13

You are a developer for a data science team. The team uses a shared module 'utilities' located at /team/shared/utilities.py. This module is not part of any package, and they want to import it from various project scripts without copying the file. Some projects are in /home/user/proj_A/ and others in /var/data/proj_B/. Currently, each script manually adds /team/shared/ to sys.path using sys.path.insert(0, '/team/shared/'). This works but is repetitive. The team wants a cleaner solution that also works when the script is run from different working directories. They consider creating a package 'utilities' by adding an __init__.py to the directory and using relative imports. However, the module currently uses absolute imports for some external libraries. What is the best course of action to allow clean imports of utilities from any location while minimizing changes to the module itself?

Accepted Answer

Set the PYTHONPATH environment variable to include /team/shared/ in the shell profile.. Option C is correct. PYTHONPATH is an environment variable that Python checks for additional module search paths. Setting it once system-wide or per user avoids modifying sys.path in each script. Option A is wrong because relative imports would require restructuring the module into a package, which changes import behavior and may break existing absolute imports. Option B is wrong because __init__.py alone does not make the module discoverable from any path; it still requires the directory to be on sys.path. Option D is wrong because installing a .pth file is system-wide and may not be allowed; also it modifies the search path globally, which is less controlled than PYTHONPATH.

Answer

Create an empty __init__.py in /team/shared/ to make it a namespace package.

Answer

Place a .pth file in the site-packages directory that points to /team/shared/.

Answer

Convert utilities.py into a package by adding __init__.py and using relative imports inside.

Question 14

Your company has two separate Python packages: 'app' and 'lib'. They are maintained by different teams. 'app' depends on 'lib', but 'lib' is still under development and its API changes frequently. To avoid breaking 'app', the team decides to use a virtual environment and install a specific version of 'lib'. However, during development, they need to test 'app' with the latest 'lib' changes from the Git repository. The current workflow is: (1) activate virtual env, (2) install 'lib' from local source using `pip install -e /path/to/lib`. This installs 'lib' as a development package. But one developer reports that after pulling latest 'lib' changes, importing 'lib' in 'app' still uses the old version even after re-running pip install -e. What is the most likely reason?

Accepted Answer

The editable install may still point to an old copy of the library if the source directory was moved or if there is a stray .egg-link file.. The most likely reason is D. When using `pip install -e` (editable install), pip creates a special `.egg-link` file (or similar pointer) in the site-packages directory that points to the source directory. If the source directory was moved, renamed, or if a stale `.egg-link` file remains from a previous install, pip may still reference the old location, causing the old version to be imported even after re-running the install command. This is a known subtlety of editable installs, especially when the source code is managed under version control and the directory structure changes.

Answer

Python caches imported modules in sys.modules, so importing again does not reload the module from disk.

Answer

The package 'lib' is being imported as a namespace package, so changes are not picked up.

Answer

The .pyc files are not being invalidated because the timestamps are not updated.

Question 15

A company has a large Python application that uses multiple packages from different directories. The application's main entry point is at /opt/app/main.py. There is a package 'common' located at /opt/app/common/ and another package 'services' at /opt/app/services/. Both packages have __init__.py files. Additionally, there is a third-party package 'utils' installed in the system site-packages. Recently, a developer added a new module 'helpers.py' to the 'common' package. When trying to import 'common.helpers' from a script inside 'services', an ImportError is raised: 'No module named common.helpers'. However, importing 'common' itself works. The sys.path includes /opt/app/ and the site-packages. What is the most likely cause of the import failure?

Accepted Answer

There is another 'common' package elsewhere in sys.path that shadows the intended one, and the shadowed package does not have a 'helpers' submodule.. Option B is correct because the most likely cause is that a different 'common' package (without a 'helpers' submodule) appears earlier in sys.path and shadows the intended /opt/app/common/ package. Since sys.path includes /opt/app/ and site-packages, if a 'common' package exists in site-packages or another directory listed before /opt/app/, Python will import that shadowed package instead, and it lacks the newly added 'helpers' module. This explains why importing 'common' succeeds (the shadowed package exists) but 'common.helpers' fails.

Answer

The 'helpers.py' file was added after the Python interpreter started, and sys.modules caching prevents new imports.

Answer

The PYTHONPATH environment variable is not set, so the /opt/app/ directory is not searched.

Answer

The 'common' package itself is already imported and cached, so adding a new module does not become visible.