Python json has no loads attribute: inspect the imported file before reinstalling
By ON Lab · Sources checked November 8, 2026
If import json succeeds but json.loads is missing, inspect json.__file__ before reinstalling anything. A local file named json.py can be imported instead of Python's standard-library package. Rename the conflicting local file, then verify the import in a fresh Python process. This is one possible cause, not a diagnosis of every AttributeError.
The reader question reviewed here reported that a short JSON example worked in an interpreter but failed when saved as a script. We verified the shadowing mechanism with a small local fixture on Python 3.9. The original question used an older Windows environment; our test does not reproduce that IDE or every detail of its setup.
Distinguish finding a module from finding the right module
A missing-module error and a missing attribute are different observations. With ModuleNotFoundError, Python could not find a requested module in that execution context. With an AttributeError on json.loads, something was bound to json, but it did not expose the attribute the code expected.
The first useful question is therefore “what object did this process import?” Use the actual failing execution route and inspect:
import sys
import json
print(sys.executable)
print(json.__file__)
print(hasattr(json, "loads"))
Record the full traceback as well. If the import itself fails because a partially initialized module raises an error, the traceback's file paths may show the conflicting local script before you reach the inspection lines. Do not assume that merely seeing the word “circular” proves a third-party dependency cycle.
Why the script directory matters
Python's module tutorial documents the module search path, including the directory containing the input script. A local module with a standard-library name can therefore change what an import finds. Running a short command from another directory is not necessarily the same import context as running the saved script.
Inspect your own script and its directory for json.py or a conflicting local package name. Use the path evidence from the failing run rather than renaming unrelated files across the computer. Do not modify Python's standard-library installation.
Our local before-and-after check
We created a temporary directory containing two files. The first, json.py, contained only a harmless marker variable. The second, probe.py, imported json, printed its module path and tried to parse a short JSON string.
import json
print(json.__file__)
print(json.loads('{"ok": true}'))
The first run printed the path to our local json.py and then failed because that module had no loads attribute. No package installation was involved. The local file was being found successfully; it was simply the wrong module for the intended operation.
We renamed our conflicting file to local_json_notes.py and ran the same probe in a new Python process. The printed path now pointed to the standard-library json package, and the parsed result contained ok: True. We checked both the module identity and the actual parse output. The fixture did not require deleting every cache directory or reinstalling Python.
This is the verified scope: one local naming collision and one fresh-process retry. It does not establish that renaming a file repairs every import customization, package corruption or runtime reassignment.
Why a fresh process is part of the check
A running Python process retains imported modules. Renaming a source file on disk does not necessarily replace an object already loaded into a long-running console or kernel. After an intended local rename, rerun the small probe in a new process and inspect the module path again.
If you use an IDE, confirm that the rerun actually restarts the execution context you mean to test. Do not infer a fresh process from a new editor tab. The original interpreter and script-directory observations remain useful if the result still differs.
If the path is already the standard library
Stop treating a local filename collision as established. Preserve the exact traceback and the code around the import and attribute access. Check whether the program reassigns the name json, imports a different object under that name or fails earlier in a dependency. Those are different hypotheses and need their own evidence.
Also inspect the argument passed to loads. Restoring the correct module does not make every argument valid JSON text. A separate error after the import fix should be handled as a new observation, not hidden behind the original missing-attribute message.
Keep a small, reusable verification
- Use a script name that does not shadow the module being tested.
- Record the interpreter and imported module file path.
- Test one literal non-confidential JSON string before adding file I/O or application logic.
- Retest in a fresh process after an intended rename.
- Keep any new error distinct from the original AttributeError.
If the module is not found at all after a pip installation, use the installation versus interpreter checklist. That addresses a package in a different environment, while this guide addresses importing the wrong local module from the current environment.