Introduction

eval and ast.literal_eval can both turn text into Python values, but they do not solve the same problem. eval executes a Python expression, while ast.literal_eval parses only literal data structures, which makes it far safer for input that might not be fully trusted.

What eval Really Does

eval does not just parse text. It executes Python expressions inside the interpreter.

expr = "2 + 3 * 4"
print(eval(expr))

This prints 14, which makes eval look convenient. The danger is that the input string can contain much more than arithmetic.

payload = "__import__('os').getcwd()"
print(eval(payload))

That code performs an import and a function call. If the string comes from a user, a file, or a network response, eval is effectively letting outside input run code in your process.

What ast.literal_eval Allows

ast.literal_eval is intentionally narrow. It accepts only Python literal structures such as:

• strings
• numbers
• tuples
• lists
• dictionaries
• booleans
• 'None'

1import ast
2
3text = "{'name': 'alice', 'age': 30, 'active': True}"
4value = ast.literal_eval(text)
5
6print(type(value))
7print(value['name'])

This is useful when the input is supposed to represent data instead of executable logic. If the text contains a function call or other executable syntax, literal_eval rejects it.

1import ast
2
3bad_text = "__import__('os').system('echo risky')"
4
5try:
6    ast.literal_eval(bad_text)
7except Exception as exc:
8    print(type(exc).__name__)

That failure is exactly why literal_eval is safer for parsing data-like input.

Security Is the Real Difference

The core distinction is trust. If the input can be influenced by anyone outside your fully controlled code path, eval should be treated as dangerous by default.

Developers sometimes try to reduce the risk by passing restricted globals and locals to eval. That can narrow the environment, but it does not change the fundamental problem: you are still executing code. Sandboxing Python securely is much harder than it first appears.

ast.literal_eval is not a full sandbox either, but it is a much better fit when the goal is to parse literal values rather than run code.

JSON Is Often the Better Format

If the input comes from an API, config file, or message queue, JSON is usually a better format than Python literal syntax.

1import json
2
3payload = '{"name": "alice", "age": 30}'
4data = json.loads(payload)
5
6print(data['age'])

JSON is standardized, language-neutral, and easier to share across systems. ast.literal_eval is helpful when you specifically have Python-style literal text, but it should not be your first choice for general data exchange.

If You Need Expressions, Build a Narrow Evaluator

Sometimes the reason people reach for eval is that they want very small expression support, such as basic arithmetic in a rules field. In that case, a dedicated parser is usually safer and easier to reason about.

1import ast
2import operator as op
3
4OPS = {
5    ast.Add: op.add,
6    ast.Sub: op.sub,
7    ast.Mult: op.mul,
8    ast.Div: op.truediv,
9}
10
11def safe_math(node):
12    if isinstance(node, ast.Constant):
13        return node.value
14    if isinstance(node, ast.BinOp):
15        return OPS[type(node.op)](safe_math(node.left), safe_math(node.right))
16    raise ValueError("Unsupported expression")
17
18expression = "3 + 4 * 2"
19tree = ast.parse(expression, mode="eval")
20print(safe_math(tree.body))

This approach explicitly defines what syntax is allowed. That is much safer than exposing general Python execution.

When eval Can Still Be Acceptable

There are narrow cases where eval is acceptable, such as internal tooling where the input is fully authored by trusted developers and dynamic expression support is intentional. Even then, it should be treated as a conscious design choice rather than a convenience parser.

If you use eval, document why the input is trusted and why a safer parser was not sufficient.

Common Pitfalls

The most common mistake is using eval as a shortcut for parsing user input because it feels convenient. That shortcut can quickly become a serious security bug.

Another mistake is assuming restricted globals automatically make eval safe. They may reduce risk in some cases, but they do not remove the fact that arbitrary code execution is the underlying behavior.

Developers also sometimes expect ast.literal_eval to handle expressions like 2 + 2. It will not, because it parses literals, not arbitrary expressions.

Finally, if the data is already JSON, use json.loads instead of forcing a Python-literal workflow.

Summary

• 'eval executes Python expressions and should be avoided for untrusted input.'
• 'ast.literal_eval parses only literal Python data structures.'
• Use JSON for most external data interchange.
• Build a narrow parser when you need limited expression support.
• Treat eval as a security-sensitive tool, not a generic parser.