Parse Python Literals Without eval

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Sometimes a program receives text that looks like a Python list, tuple, number, or dictionary. The tempting shortcut is `eval(text)`, because it converts many expressions into values. But `eval` evaluates Python expressions. If the text comes from an untrusted source, that gives the text far more power than a data parser should have. `ast.literal_eval` is a narrower standard- library function that accepts Python literal structures while rejecting general expressions. Today we will show the distinction without running any harmful input. We will then build a small parser that also checks the expected result type and input length.

2. 00:42

   Even `literal_eval` is not a limitless safety boundary: very large or deeply nested input can still consume resources. If you control the data format, JSON is often the clearer interchange format. This lesson is about a specific situation where the input is intentionally Python- literal syntax. Watch the actual runs and ask what the parser is allowed to create, not merely whether it returns something for one string. The first string looks like a list literal, and `eval` returns a list. The second string is an arithmetic expression, and `eval` computes it. We intentionally use a harmless expression so the demonstration is safe, but the

3. 01:25

   capability is the warning: this is execution, not limited data parsing. If a program accepts arbitrary text from a form, a file, or a message and passes it to `eval`, it has crossed a trust boundary. Filtering a few suspicious words is not a reliable repair, because Python expressions can be written in many forms. We need a parser whose permitted language is narrower by design. It is also worth checking the output type. Even if a string is a valid literal, receiving a dictionary when the application expects a list can cause a different class of bug. We will use `literal_eval` for the syntax boundary and an explicit type check for

4. 02:06

   the application contract. `literal_eval` accepts the list and dictionary literal syntax. It rejects the arithmetic expression because that is not a literal structure. This is a much better match for a program that expects data rather than behavior. The allowed forms include basic literal values and containers; it does not resolve arbitrary variable names or call functions. That restriction is the feature. However, accepting any literal does not mean the result is suitable for our use. The dictionary in this run is valid literal syntax, but a feature expecting a list of integers should reject it.

5. 02:48

   Also, the parser can still consume memory or stack resources if given extremely large or deeply nested input. The documentation explicitly warns against treating it as entirely safe for untrusted, unbounded data. Limit input size and complexity at the application boundary. For a regular configuration or network format, prefer a format with a clear schema and parser, such as JSON, when it matches the product's needs. The helper limits input length before parsing, calls `literal_eval`, and turns parser failures into a clear application error. It then checks for exactly the data shape we need: a list whose members have type

6. 03:29

   `int`. We use `type(item) is int` here because Python's `bool` is a subclass of `int`; a plain `isinstance(True, int)` would accept a Boolean score. Whether that is desirable depends on the application, but for this example we want actual integer scores. The 200-character limit is illustrative and does not by itself guarantee a strict memory bound for every form of input. A production service should set limits based on its threat model and test them. We also do not make arbitrary expressions safe by catching exceptions around `eval`; the important fix is the parser choice.

7. 04:09

   If you have a JSON array from an API, use `json.loads` instead of parsing Python syntax. Choose one format deliberately, validate the resulting data, and reject unexpected types early. The valid list passes. The arithmetic expression is rejected by the literal parser. The dictionary is a valid literal but the wrong shape for scores. The list with `True` is also a valid literal and a list, yet it violates the exact integer-item rule. That sequence shows three separate checks: allowed syntax, expected container, and expected element type. A program that stops after only the first check still needs to handle wrong-shape

8. 04:51

   data somewhere else. Try adding a very long input string and observe the explicit length error before parsing. Then try a tuple such as `(1, 2)` and explain why our parser rejects it even though it is literal syntax. The application's contract says list. The takeaway is to avoid converting untrusted text into executable Python code, select an appropriate data parser, and validate the result's shape and limits. Complete the practice task by accepting one intended data form and showing that both an expression and a wrong type fail cleanly.