PCAP Modules and Packages Practice Question

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 user did not restart the Python interpreter, so sys.modules still contains the old module.

  Why it's wrong here

  This explanation fails because the problem statement explicitly says the user restarted the application. On a fresh interpreter start, sys.modules is rebuilt from scratch, so any modules imported in the previous run are gone; there is no persistent sys.modules across processes. The stale-code symptom therefore cannot be attributed to an interpreter that was never terminated, because the restarted Python process would not retain old module objects.

• ✗

  The import statement in __init__.py is cached, so the module is not reloaded even after update.

  Why it's wrong here

  The import statement in __init__.py is not cached by Python in any persistent sense; every import of the package re-executes that statement within the new process. What can persist across installations, however, is a stale .pyc file on disk: the import system may re-use cached bytecode if the source file's timestamp looks unchanged. Thus the statement itself always runs, but it loads bytecode that may predate the updated source, which is the real reason the new code does not appear.

• ✓

  The library's .pyc files were not regenerated because the .py timestamps were not updated during the install, so Python used the cached bytecode from the previous version.

  Why this is correct

  Python's import machinery validates cached bytecode by comparing the source file's modification time (and often size) with the values stored in the .pyc header. If an installer copies only the .py files without updating their mtimes—for example, by preserving timestamps from the build or using a tool that does not touch the destination files—the old .pyc still appears to match the unchanged source timestamp. Python then loads the stale bytecode instead of recompiling, so even though the .py file on disk contains the new code, the interpreter executes the previous version.

• ✗

  The config module caches the configuration file contents in memory after the first read.

  Why it's wrong here

  An in-memory cache inside a config module would only matter after the new module code is actually executed; it cannot explain why the freshly restarted Python process still runs old library code. If the library's .py files were modified but the old .pyc was used, the config module itself was never re-imported from the new source. This option incorrectly shifts the cause from the bytecode caching layer to application-level memoization, which is both unrelated and unsupported by the symptom of a library update not taking effect.

Go deeper

Related to this question