If a Python import reads your own file instead of the standard library, check whether the file is named inspect.py

While scoring kept failing in an automated content pipeline (content-loop-mvp), I was writing a small diagnostic script to print per-criterion scores. The script wouldn't run on Windows 11, and a file named inspect.py was blamed.

Conclusion

When Python resolves a module, it searches the folder the running script lives in *before* it searches the standard library (the modules that ship with Python itself). So if inspect.py sits in that same folder, import inspect reads that file instead of the standard library's inspect. One line confirms it either way:

python -c "import inspect; print(inspect.__file__)"

If the printed path points inside your own project folder, the standard library has been shadowed.

In this session, that one line was never actually run. The script was renamed and re-run, but an old inspect.py left over in a scratch folder was still being picked up from the same spot , and the record cuts off right there once the session hit its turn limit .

If renaming doesn't fix it and the same error keeps showing up in the same place, do these three things:

1. Delete the old inspect.py. If you don't want to delete it, move it to a different folder.
2. In the folder you're running from, list *.py (dir *.py on Windows, ls *.py on Mac/Linux) and check whether any other file shares a name with a standard library module.
3. Re-run the one-liner above and confirm inspect.__file__ now points at the standard library path.

Situation

content-loop-mvp is a Korean-language content pipeline: it generates topic candidates, gathers and cross-checks evidence from the web, writes the article, then has a separate model screen it — only articles that pass get saved. Originally all four stages required an OpenAI or Gemini API key to run . In this session, the decision was made to skip API keys entirely and shell out to the Claude and Codex CLIs as subprocesses to stand in for the model calls . All four stages actually running on Claude came after that . The condition was that the bar (minimum topic score of 75) would not be lowered .

The problem: even with the bar unchanged, five runs in a row produced zero articles. The highest topic score stayed at 74 . Adding per-criterion grading instructions to the scoring prompt and re-running still capped out at 72–74 . So the plan became: write a one-off diagnostic script to print one candidate's score, broken down by criterion .

Symptom

Running the diagnostic script failed. The AI concluded "the file is named inspect.py, which conflicts with the standard library's inspect" and decided to rename it and re-run . But the record doesn't contain the actual error message — there's no line confirming what the error actually was, or that it was really caused by the inspect shadowing.

Cause

The only cause on record is "because the file is named inspect.py." The name does collide with a standard library module, and the one-liner above would confirm the shadowing immediately — but in this session, that confirmation never happened. So this can't be written up as a confirmed cause for this session.

Fix

The plan was to rename the file and re-run, but the old inspect.py left behind in the scratch folder was still being picked up from the same location . Right as the old file was about to be deleted and re-run, the session hit its turn limit . So this article can't claim "fixed." The fix only counts as done once the old file is removed and the one-liner confirms which file is actually being read.

Bonus — renaming the file and removing the old one are not the same thing

Renaming avoids the new file being shadowed, but an old file left in the same folder keeps getting picked up regardless of what you rename the new one to. After renaming, list the folder again and check there isn't another .py file sharing a name with a standard library module. Putting a diagnostic script in a scratch/temp folder sets the same trap.

Reporter's Notes — thought renaming one file would be the end of it

A diagnostic script meant to print per-criterion topic scores won't run. There's no note quoting the actual error message.

Jung Bada

The diagnostic script won't run. I built it to see why the topic score is stuck at 74, but I think the problem is the filename inspect.py — it collides with the standard library's inspect

Jung Haneul

How did you confirm the error is actually about inspect? Same name is a guess — have you actually seen which file got read?

Jung Bada

I know Python searches the folder you ran from first. Same name means it obviously reads my file

Park Doeun

Wait, what does "searches first" even mean? I thought Python just finds things automatically when you import

Jung Bada

There's a search path list. The first entry is the folder you ran from, so if inspect.py is there, it gets picked up before the standard library. So renaming it should be the end of it

Park Dohyun

"Renaming is the end of it" is the most expensive assumption here. How do you tell "fixed" apart from "just hidden"?

Jung Haneul

If Bada's right, inspect.__file__ should print our folder's path. Until you print it, it's just a hypothesis

Jung Bada

Printing it can wait. I'll rename it first and re-run

Park Doeun

You renamed it and it's still hitting the same spot? The old inspect.py was still sitting in the scratch folder

Jung Bada

Oh — the renamed one is a new file, but the old one was still there. As long as that file exists, it gets picked up no matter what you rename the new one to

Park Dohyun

So what's the actual state right now? Fixed, or just hidden?

Jung Haneul

Neither. Deleting the old file and printing the result was supposed to be next, but the day's turn budget ran out right there

Park Doeun

So we still don't know the outcome?

Jung Bada

Right, nobody knows yet. Until we print it, even the cause is just a hypothesis

Park Dohyun

Then there's one lesson left: grab the actual error message first, confirm the hypothesis in one line, and only then rename anything