PCAP Modules and Packages Practice Question
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?
⚠ Common exam trap
Python Institute often tests the distinction between source file modification and module caching, where candidates mistakenly think the issue is with bytecode caching (`__pycache__`) or path resolution, rather than the `sys.modules` cache that prevents re-execution of the module's code.
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
✓
Python's module caching in sys.modules prevents re-loading the modified source.
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 analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The sys.path is altered by the egg-link, causing a different module to be loaded.
Why it's wrong here
This option misattributes the failure to sys.path manipulation. An .egg-link file adds the development project's directory to sys.path so the import system finds the project's own modules; if a different module with the same name is present earlier on sys.path, it could shadow the project, but that is a separate configuration problem. In normal usage, the egg-link's sys.path change makes the correct module visible, and the reason edits are not reflected is that the first import stored the module object in sys.modules, not because a different module was loaded.
- ✗
Relative imports are cached in the __init__.py file.
Why it's wrong here
Relative imports are resolved during the execution of the `__init__.py` file and are bound to the package's namespace at that moment; the `__init__.py` does not serve as a cache for import statements. The import machinery checks `sys.modules` before attempting to load any submodule or package, and it is that module-level cache, not anything stored in `__init__.py`, that serves subsequent imports of the package. Therefore, editing source files without restarting or reloading leaves the cached module objects in place.
- ✓
Python's module caching in sys.modules prevents re-loading the modified source.
Why this is correct
When a module is first imported, Python stores the resulting module object in `sys.modules` under its full qualified name; every later `import` statement checks `sys.modules` first and returns that same object without re-reading the source file. In an egg-link development environment, the source directory is the one being imported, so you are editing the exact file that was loaded — but the interpreter has already cached the compiled, executed version of that module. You must use `importlib.reload(module)` or restart the process to force reparsing and re-execution of the modified `.py` file.
- ✗
The __pycache__ directory is not cleared automatically.
Why it's wrong here
The `__pycache__` directory holds pre-compiled `.pyc` bytecode files, but Python automatically invalidates them by comparing the source file's modification timestamp and size against the header stored in the `.pyc` file. As long as the source file is newer, the interpreter regenerates the bytecode cache, so a stale `__pycache__` alone cannot make your edits invisible. The reason changes are not seen is the higher-level `sys.modules` cache, which short-circuits the entire import process before bytecode translation even matters.
Go deeper
Related to this question
About these practice questions
One of 169 original PCAP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.