Introduction

Python's eval() takes a string, parses it as a Python expression, and returns the result of evaluating that expression. It is powerful because it can interpret dynamic input using a chosen global and local context. It is also dangerous because evaluating untrusted input can execute behavior you did not intend, which makes eval() one of the easiest ways to create a serious security problem.

What eval() Accepts

eval() is for expressions, not full statement blocks. That means it can evaluate things such as arithmetic, list literals, function calls, and variable references.

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

This prints 14.

You can also provide execution context:

1globals_dict = {"tax_rate": 0.2}
2locals_dict = {"price": 100}
3
4result = eval("price * (1 + tax_rate)", globals_dict, locals_dict)
5print(result)

That makes eval() look flexible, but it also shows why it is risky: the evaluated expression can use whatever names and functions are available in the context you expose.

eval() Executes Python Semantics, Not Just Math

Many people think eval() is only for parsing math expressions. It is not. It evaluates arbitrary Python expressions, which can involve attribute access and function calls.

Example:

name = "Alice"
print(eval("name.upper()"))

That is legal because name.upper() is a Python expression.

This is the reason security warnings around eval() are so strong. If the string comes from an untrusted source, the user may be able to run far more than the developer intended.

Restricting Context Helps but Does Not Make It Automatically Safe

You can limit the available names:

1safe_globals = {"__builtins__": {}}
2safe_locals = {"x": 10, "y": 5}
3
4print(eval("x + y", safe_globals, safe_locals))

This reduces what the expression can access, but "restricted eval" is still a tricky security topic. It is very easy to believe the environment is safe while leaving a route to abuse through exposed objects or callable references.

So the practical rule is simple: if the input is not fully trusted, do not use eval() unless you are extremely sure about the threat model and the exposed objects.

Prefer ast.literal_eval for Data Literals

If the string represents a Python literal such as a list, dict, number, or string, use ast.literal_eval instead.

1import ast
2
3value = ast.literal_eval("[1, 2, 3]")
4print(value)
5print(type(value))

literal_eval supports simple Python literal structures but rejects arbitrary expressions such as function calls. That makes it much safer for configuration-style parsing.

This is the right replacement for many uses of eval() that were really about reading data, not executing code.

Know the Difference Between eval() and exec()

eval() returns the value of an expression:

print(eval("3 * 7"))

exec() runs statements and does not return an expression value:

code = "x = 5\nprint(x)"
exec(code)

If you mix these up, the code often becomes confusing quickly. If the goal is "compute one expression result," eval() is the relevant function. If the goal is "run a block of Python statements," that is exec().

Neither should be used on untrusted input casually.

Common Pitfalls

• Using eval() to parse plain data when ast.literal_eval would be much safer.
• Assuming eval() is limited to arithmetic instead of full Python expression semantics.
• Passing untrusted input into eval() and exposing the program to code execution risks.
• Believing a lightly restricted globals dictionary automatically makes eval() safe.
• Confusing eval() and exec() when deciding how dynamic code should be handled.

Summary

• 'eval() evaluates a string as a Python expression and returns the result.'
• It can use custom globals and locals, which makes it flexible but risky.
• It is not just for math; it can evaluate arbitrary Python expressions.
• For parsing literals, prefer ast.literal_eval.
• Avoid eval() on untrusted input unless you have a very strong and well-tested safety model.