PCAP Modules and Packages — 40 Questions

Question 1

A developer creates a package named 'analytics' with the following structure:

analytics/
    __init__.py
    stats.py
    models/
        __init__.py
        regression.py

The developer wants the statement 'from analytics import *' to import only the functions 'mean' and 'std' from stats.py. What should be added to analytics/__init__.py?

Accepted Answer

from analytics.stats import *. To make `from analytics import *` export only `mean` and `std`, the desired functions must be imported into the package namespace (e.g., `from analytics.stats import mean, std`) AND `__all__ = ['mean', 'std']` must be set in analytics/__init__.py. Option B alone imports everything public from stats.py, so it does not satisfy 'only'. Option D sets `__all__` but does not import the names. None of the provided options is fully correct.

Answer

Nothing; by default, all names are exported.

Answer

__all__ = ['stats.mean', 'stats.std']

Answer

__all__ = ['mean', 'std']

Question 2

A developer is creating a package that contains a subpackage. The subpackage has an __init__.py file that imports a module named 'helper' from the parent package. Which import statement in the subpackage's __init__.py will correctly import 'helper'?

Accepted Answer

from mypackage import helper. Both option A and option D are correct ways to import 'helper' from the parent package. Option A uses an absolute import, explicitly naming the parent package (mypackage), which is unambiguous and follows best practices. Option D uses a relative import with '..' to refer to the parent package, which is a valid syntax and also works when the subpackage is part of a package. Relative imports are concise but can be less clear. Options B and C are incorrect: 'from . import helper' would try to import from the current package, and 'from ... import helper' uses too many dots, referring to the grandparent, not the parent.

Answer

from . import helper

Answer

from ... import helper

Question 3

Which TWO of the following are valid ways to import a module named 'math' and give it an alias 'm'?

Accepted Answer

import math as m. Only B. Option B uses the correct syntax `import math as m` to import the entire math module with alias m. Option A is invalid because the asterisk (*) cannot be combined with an alias in a `from ... import` statement. Option C is missing the `as` keyword. Option D uses `alias` which is not a valid keyword; the correct keyword is `as`. Option E imports a specific function (sin) from math, not the module itself; therefore it does not satisfy the requirement to import the module and give it an alias.

Answer

from math import * as m

Answer

import math m

Answer

import math alias m

Answer

from math import sin as m

Question 4

You are a developer at a company that builds a data processing pipeline. The pipeline consists of several Python modules organized in a package called 'pipeline'. The package structure is:

pipeline/
    __init__.py
    load.py
    transform.py
    analyze.py

The pipeline is deployed on a server where Python 3.8 is installed. The server also has a globally installed package called 'pipeline' (from a different project) in the site-packages directory. When you run your scripts that import 'pipeline', you get unexpected behavior because Python is importing the wrong package. You need to ensure that your local 'pipeline' package is used instead of the global one. You cannot uninstall the global package because it is used by another application. You have the following options:

A) Modify the PYTHONPATH environment variable to include the directory containing your 'pipeline' package before the site-packages directory.
B) Rename your local 'pipeline' package to something else and update all imports.
C) Use a virtual environment specific to your project and install your package there.
D) Add an __init__.py file with a special import hook to override the global package.

Which course of action is the most appropriate and reliable?

Accepted Answer

Use a virtual environment specific to your project and install your package there.. Using a virtual environment creates an isolated Python environment where you can install your local 'pipeline' package without affecting or being affected by the globally installed package. This is the most reliable approach as it ensures that Python's import system will search the virtual environment's site-packages before the global site-packages, preventing any naming conflicts. Virtual environments are the standard Python best practice for managing project-specific dependencies and avoiding package name collisions.

Answer

Modify the PYTHONPATH environment variable to include the directory containing your 'pipeline' package before the site-packages directory.

Answer

Rename your local 'pipeline' package to something else and update all imports.

Answer

Add an __init__.py file with a special import hook to override the global package.

Question 5

A developer is troubleshooting a Python application that fails to import a custom module named 'utils'. The file 'utils.py' exists in the same directory as the main script. Which of the following is the most likely cause of the import failure?

Accepted Answer

The utils.py file contains a syntax error.. When a Python script is executed directly (e.g., python main.py), Python sets sys.path[0] to the directory containing the script. Since utils.py is in the same directory as the main script, it should be found by the import system. Therefore, a failure to import utils.py is not caused by the directory being absent from sys.path. The most plausible cause from the given options is that utils.py contains a syntax error, which raises a SyntaxError during compilation and prevents the module from being loaded.

Answer

There is a circular import between utils.py and the main script.

Answer

The directory containing utils.py is not in sys.path.

Answer

The directory lacks an __init__.py file.

Question 6

A Python package 'shapes' has the following __init__.py:

# shapes/__init__.py
from .circle import Circle
from .square import Square

A user writes:

import shapes
c = shapes.Circle(5)

This works correctly. However, when the user writes:

import shapes.circle
c = shapes.circle.Circle(5)

It fails with AttributeError: module 'shapes' has no attribute 'circle'. What is the most likely reason?

Accepted Answer

The submodule 'circle' is not added to the package's namespace because the __init__.py does not import it as a submodule.. In Python, importing a submodule always sets it as an attribute of the parent package. Both `import shapes.circle` and `from .circle import Circle` in `__init__.py` cause the `circle` submodule to be loaded and attached to `shapes`. Therefore, after `import shapes.circle`, `shapes.circle.Circle` is accessible. The scenario described in the stem is not a real error.

Answer

The __init__.py file must include 'import shapes.circle' to make the submodule accessible.

Answer

The submodule name 'circle' conflicts with the class name 'Circle' due to case sensitivity.

Answer

The import statement 'import shapes.circle' is invalid because submodules must be imported using 'from' syntax.

Question 7

You are working on a Python-based data processing pipeline that runs on a Linux server. The pipeline consists of several custom packages and modules located in /opt/mypipeline. The directory structure includes:

/opt/mypipeline/
    __init__.py
    core/
        __init__.py
        processor.py
    utils/
        __init__.py
        logger.py

The main entry point is /opt/mypipeline/run.py, which imports modules from core and utils. The pipeline is executed using the command:

python /opt/mypipeline/run.py

Recently, the system administrator added a new Python package 'external_lib' to /opt/external_lib, and updated the PYTHONPATH environment variable to include /opt/external_lib. However, after this change, the pipeline fails to start with the following error:

ImportError: cannot import name 'process' from 'core.processor' (unknown location)

You check the PYTHONPATH and find it contains:

/opt/mypipeline:/opt/external_lib

The 'core.processor' module defines a function 'process' that is imported in run.py as:

from core.processor import process

The 'core' package has an __init__.py file. The 'external_lib' package also has a subpackage named 'core' with an __init__.py. What is the most likely cause of the import error?

Accepted Answer

The 'external_lib' package contains a 'core' subpackage that shadows the 'core' package from mypipeline, and Python is resolving to the wrong one.. The most likely cause is that the 'external_lib' package contains a 'core' subpackage that shadows the 'core' package from mypipeline. When Python resolves the import 'from core.processor import process', it searches the directories in PYTHONPATH. Although /opt/mypipeline is listed before /opt/external_lib, the presence of another 'core' package can cause Python to incorrectly resolve to the external_lib's core due to namespace package conflicts or import system quirks, especially when both packages have __init__.py files. Since external_lib's core does not contain a 'processor' module, an ImportError occurs.

Answer

The __init__.py file in /opt/mypipeline/core/ is missing or empty.

Answer

The import statement in run.py is incorrect; it should use 'from core.processor import process as process' or similar.

Answer

The PYTHONPATH environment variable is set incorrectly; it should include /opt/mypipeline before /opt/external_lib.

Question 8

Given the exhibit, why does `dir()` show no names from `mypackage` after executing `from mypackage import *`?

Accepted Answer

The `__all__` variable is defined as an empty list, so `from mypackage import *` imports nothing.. When a package defines `__all__` as an empty list in its `__init__.py`, the `from mypackage import *` statement imports nothing. The `__all__` variable explicitly controls which names are exported by `import *`, and an empty list means no names are imported. This is a deliberate design to prevent accidental namespace pollution.

Answer

The package does not have an `__init__.py` file.

Answer

The `__init__.py` file must be empty for `from package import *` to work.

Answer

`__all__` causes submodules to be ignored during `import *`.

Question 9

A script is located in the parent directory of a package named 'mypackage'. Which import statement correctly imports the 'foo' module from the 'mypackage' package?

Accepted Answer

from mypackage import foo. Both 'from mypackage import foo' and 'import mypackage.foo' correctly import the foo module from the package. The first binds the name foo directly; the second binds the package name mypackage and allows access to the submodule as mypackage.foo. Option C is invalid because relative imports require a package context, and option D has incorrect syntax.

Answer

from .mypackage import foo

Answer

import foo from mypackage

Question 10

Refer to the exhibit. A script executes 'from mypackage import *'. Which functions are available in the global namespace?

Accepted Answer

None, because __all__ lists modules, not functions. When `from mypackage import *` is executed, Python looks for the `__all__` list in the package's `__init__.py` file. In this exhibit, `__all__` is defined as `['module_a', 'module_b']`, which are module names, not function names. The `import *` statement imports the modules listed in `__all__` into the global namespace, not their individual functions. Therefore, `func` from either module is not directly available; you would need to reference them as `module_a.func` or `module_b.func`.

Answer

Only func from module_a

Answer

It raises an ImportError because __all__ should contain function names

Answer

func from both module_a and module_b

Question 11

A Python application needs to load a configuration file that should be placed in the same directory as the main script. The developer uses the __file__ attribute to get the script's path. Which expression correctly obtains the directory containing the main script?

Accepted Answer

os.path.dirname(os.path.realpath(__file__)). os.path.realpath(__file__) returns the canonical path of the script, resolving any symbolic links. This ensures that the directory returned is the one where the actual script file resides, which is where the configuration file should be placed. os.path.abspath(__file__) only makes a relative path absolute and normalizes it, but it does not follow symlinks; if the script is executed via a symlink, abspath returns the symlink's directory, which may not contain the configuration file.

Answer

os.path.dirname(os.path.abspath(__file__))

Answer

os.getcwd()

Answer

os.path.abspath(__file__)

Question 12

Which TWO of the following are valid ways to import a function 'foo' from a module 'bar' that is located in a package 'mypackage'?

Accepted Answer

from mypackage.bar import foo. Option B is correct because 'from mypackage.bar import foo' uses the dotted module path to import the module 'bar' from the package 'mypackage' and then binds the name 'foo' directly into the current namespace, which is the standard way to import a function from a submodule. Option C is correct because 'import mypackage.bar' imports the submodule 'bar' and binds the top-level name 'mypackage' in the namespace, so the function can then be accessed as 'mypackage.bar.foo' (or, after importing, the attribute chain 'bar.foo' is reachable through the package reference) — this is a valid two-step import approach. Option A is invalid because 'from mypackage import bar.foo' attempts to import a dotted name after 'import', which is a syntax error in Python. Option D is invalid because 'from . import bar.foo' likewise uses a dotted name after 'import', which is not allowed. Option E is invalid because 'import mypackage.bar.foo' treats 'foo' as a module to import, but 'foo' is a function, not a module, so this raises a ModuleNotFoundError.

Answer

from mypackage import bar.foo

Answer

from . import bar.foo

Answer

import mypackage.bar.foo

Question 13

A Python script placed in /opt/myapp/script.py fails with ImportError when run from a cron job with the command: python /opt/myapp/script.py. The script works when run manually from the /opt/myapp/ directory. The script contains the line: from . import config. The config module is located in /opt/myapp/lib/config.py with an __init__.py in /opt/myapp/lib/. What is the most likely cause of the failure?

Accepted Answer

Relative imports are not allowed in a script that is executed directly because its __name__ is not set to a package name.. When a Python script is executed directly (e.g., `python /opt/myapp/script.py`), its `__name__` is set to `'__main__'`, not to a package name. Relative imports (like `from . import config`) require the importing module to be part of a package with a proper `__name__` reflecting the package hierarchy. Since the script is run as the top-level entry point, the relative import fails with an `ImportError`. This explains why the script works when run manually from `/opt/myapp/` (if the working directory is set appropriately, but the relative import still fails unless the script is run as a module with `-m`), but fails from cron where the working directory is typically the user's home directory.

Answer

The __init__.py file in the lib directory is empty and should contain imports.

Answer

The lib directory is not in sys.path when the script is run from cron.

Answer

The cron job uses a different Python interpreter that does not have the required standard library.

Question 14

A developer appends a custom path to sys.path and then tries to import a function from a module: import sys; sys.path.append('/custom/libs'); from mylib import func. The import fails with ModuleNotFoundError. mylib is a directory. What is the most likely cause?

Accepted Answer

The mylib directory lacks an __init__.py file.. In Python, a directory is recognized as a regular package only if it contains an `__init__.py` file. Without it, Python 3.3+ may treat the directory as a namespace package, but namespace packages are intended for splitting packages across multiple directories. When using `from mylib import func`, Python expects `mylib` to be a regular package that contains the module `func`. Since `mylib` lacks `__init__.py`, it is not a regular package, leading to `ModuleNotFoundError`. While namespace packages exist, they do not allow direct import of modules within the directory unless the directory is part of a proper namespace package structure, which is not the typical scenario. Thus, the most likely cause is the missing `__init__.py` file.

Answer

The import order is wrong; sys.path.append should be after the import.

Answer

mylib.py exists in the same directory as the script.

Answer

The appended path does not exist on the filesystem.

Question 15

A developer runs pip install requests. Later, they need to find out where the module is installed on the system. Which command shows the location?

Accepted Answer

python -c "import requests; print(requests.__file__)". After importing a module in Python, its `__file__` attribute contains the absolute path to the module's `.py` file (or compiled `.pyc` file). The command `python -c "import requests; print(requests.__file__)"` first imports the module, then prints the location where Python found it, which is the exact installation path on the system.

Answer

python -c "print(requests.__path__)"

Answer

pip list --path

Answer

pip show requests

Question 16

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 17

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 18

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 19

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 20

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.