PCAP Modules and Packages Practice Question
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?
⚠ Common exam trap
A common mistake is to think that adding an __init__.py file makes a directory importable from anywhere. In reality, __init__.py only marks a directory as a Python package, but the directory must already be in the module search path (sys.path) to be imported. Without PYTHONPATH or sys.path manipulation, the package is not discoverable from arbitrary locations.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set the PYTHONPATH environment variable to include /team/shared/ in the shell profile.
Setting the PYTHONPATH environment variable to include /team/shared/ is the best solution because it automatically adds that directory to the module search path for all Python scripts without modifying the module itself or requiring repetitive code. This approach works regardless of the current working directory and preserves the module's existing absolute imports. Other options either do not add the directory to the search path, require modifying the module, or are more complex to implement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create an empty __init__.py in /team/shared/ to make it a namespace package.
Why it's wrong here
Creating an empty __init__.py inside /team/shared/ marks that directory as a regular Python package, not a namespace package, but it does nothing to add /team/shared/ to sys.path. For `import utilities` to work, the parent directory containing /team/shared/ would need to be on the search path, and the import would become `import shared.utilities` at best. This changes the module's identity and still leaves the fundamental path configuration unsolved.
- ✓
Set the PYTHONPATH environment variable to include /team/shared/ in the shell profile.
Why this is correct
Setting PYTHONPATH in the shell profile prepends /team/shared/ to the module search path (sys.path) for every Python process spawned from that shell. This allows `import utilities` to resolve cleanly without altering the module's internals, placing the shared directory in a well-known environment variable rather than hard-coding it into each script. It is minimal, reversible, and does not touch the Python installation or require packaging changes.
- ✗
Place a .pth file in the site-packages directory that points to /team/shared/.
Why it's wrong here
A .pth file placed in site-packages is read by the site module during interpreter startup, and a line containing /team/shared/ does add that directory to sys.path. However, this modifies the Python installation's site-packages directory, which is a global, system-level change requiring appropriate write permissions and affecting every virtual environment that shares that interpreter. It is less portable and more intrusive than setting PYTHONPATH because it couples the shared code to a specific Python installation's site-packages layout.
- ✗
Convert utilities.py into a package by adding __init__.py and using relative imports inside.
Why it's wrong here
Converting utilities.py into a package with __init__.py and using relative imports changes the module's internal structure. This could break existing absolute imports for external libraries and requires modifying the module, which the team wants to avoid.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PCAP question from scratch — 169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCAP practice question is part of Courseiva's free Python Institute certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCAP exam.