ast.literal_eval vs json.loads: Localhost Lab

Intro — what this post promises

Safe parsing with json.loads vs ast.literal_eval. This lab reports ops/s on Linux localhost for an object, a 100-int list, and a nested structure — both arms avoid eval.

Related links:

• selectors vs select localhost lab
• dataclass asdict vs vars localhost lab
• tracemalloc snapshot localhost lab
• sqlite3 vs shelve localhost lab
• gc collect cost localhost lab
• path read text vs open localhost lab
• intenum vs int localhost lab
• cmath vs math hypot localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. JSON text from json.dumps; Python text from repr() for literal_eval. Objects equal (equal=True).

Verdict up front (n=20000): object — json ~531562 ops/s vs literal_eval ~36193; nested — json ~192005 vs literal_eval ~6216.

Arms

Seven rounds, p50. Wire sizes: JSON 119 B, repr 138 B.

Lab topology

n=20000 · 7 rounds · p50
metric: ops/s = n / p50_s

Script: lab-evidence/137-literal-eval-vs-json/results/run_lab.py.

Lead table (p50 ops/s)

JSON led every column — roughly 14.7× on the object arm.

Reading it for SRE work

• Inter-service / config-on-disk → JSON (speed + ecosystem).
• Must accept Python literals from trusted tools (tuples, single quotes) → ast.literal_eval, never eval.
• Agent status blobs already JSON → do not “simplify” to literal_eval.
• Both are safe relative to eval; neither replaces a schema validator.

When literal_eval is still right

Admin pastes, debug __repr__ dumps, and some legacy .cfg fragments ship Python literals. literal_eval is the correct safe parser there — just budget ~36193 ops/s vs JSON’s ~531562 on similar data.

Nested structures widen the gap (json ~192005 vs literal_eval ~6216). Prefer JSON for anything on a hot ingest path.

Interchange vs debug dumps

JSON is the right default for anything that crosses a process or language boundary: ~531562 ops/s here beats literal_eval’s ~36193, and every other service already speaks it. Keep ast.literal_eval in the toolbox for trusted Python-literal pastes and __repr__ forensics — especially lists of ints where the gap grew to json ~204844 vs literal_eval ~11490.

Put a hard byte cap in front of either parser when input can be attacker-controlled; safe parsing is not the same as cheap parsing of huge trees.

If a runbook still says “just eval the blob,” replace that line with literal_eval or JSON and re-test — correctness first, then the ops/s table above.

Pitfalls

• Using eval because literal_eval “felt slow.”
• Feeding JSON (true/null) to literal_eval.
• Feeding Python repr with single quotes to json.loads.
• Skipping size limits on untrusted input (both can allocate big trees).

Reproduce

python3 lab-evidence/137-literal-eval-vs-json/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. CPython parsers only. Not orjson/ujson, not YAML.

Document which parser each config path uses so on-call does not “fix” a slow ingest by swapping JSON for repr dumps under pressure.

Measure your own payload shapes before rewriting parsers in a hot path.

Takeaway

json.loads ~531562 ops/s vs ast.literal_eval ~36193 on a small object. Prefer JSON for interchange; keep literal_eval for trusted Python-literal text only.