How to Manipulate sys.modules in Python to Intercept Judge Function Calls

How Python actually resolves an import

Python's import system is a pipeline, and the parts that matter here are visible in plain sight. When code executes 'import checker', the interpreter first consults 'sys.modules' — a live, mutable dictionary of already-loaded modules — and returns the cached object if present. Otherwise it walks 'sys.path', finds the module, executes it, and stores the result in 'sys.modules' before handing it to the importer. Everything downstream that imports the same name gets the same object: modules are singletons per interpreter.

That mutability is the entire story. 'sys.modules' is a plain dictionary that any code in the process can read and write; 'sys.path' is a plain list with the same property. Import hooks ('sys.meta_path', 'sys.path_hooks') are documented extension points that let code intercept resolution before it reaches the filesystem, and startup hooks like 'sitecustomize' execute early in interpreter initialisation, before the main program runs. The machinery is designed to be extensible, and everything that is extensible is, in a shared interpreter, reachable by every participant in the process.

The precondition for all of this is a specific architecture: the grader and the graded code must share an interpreter — or at least a namespace and a filesystem — so that one can observe and mutate the other's imports. In that architecture