AttributeError: ‘List’ Object Has No Attribute ‘Items’ | Fix

What This Python AttributeError Message Means

This message appears when Python sees a list where your code expects a dictionary with an items() method. Lists store values in order, while dictionaries store pairs of names and values. The error tells you that the object at that line is a list, so calling items() on it does not make sense to the interpreter.

Lists are ordered collections of values, indexed from zero upward. Dictionaries are mappings where each name points to a value. When you work with JSON, YAML, or many web APIs, you often get a blend of these structures: a list that wraps several mapping objects, or a mapping that holds lists under certain names. That mix makes it easy to point methods at the wrong layer.

In short, the interpreter is saying: “I found a list, and lists do not know how to give you name and value pairs.” That usually means your variable holds the wrong data type or a previous step returned a list instead of the dictionary you were expecting.

Common Situations That Trigger The Error In Real Code

This issue tends to appear in a few recurring patterns in day to day Python work. Once you learn these patterns you can spot the cause much faster when attributeerror: ‘list’ object has no attribute ‘items’ pops up in a traceback.

• Looping Over A List Like A Dictionary — You write a loop such as for name, value in data.items(), but data holds a list of values or a list of dictionaries, not a single dictionary.
• Assuming JSON Data Is Always A Dictionary — You load JSON from an API or file and call data.items() on the top level, but the JSON root is a list of objects instead of one object.
• Misreading Library Return Types — A helper call returns a list, yet you treat it like a dictionary because of a wrong memory of the documentation or a quick glance at older code.
• Mixing Up Nested Structures — You have data like [{ “id”: 1 }, { “id”: 2 }] and forget to index into the list before trying to pull name and value pairs.

Many developers first see this error while learning about list and dictionary types side by side. It also appears in more mature projects when refactors change a data structure from a dict to a list or the other way round without updating every use.

When this message appears, read the code around it and locate any place that calls items(). Then match each variable there to its actual data type. In practice that habit trains you to read tracebacks slowly and with care instead of jumping straight into random edits.

Handling The ‘List’ Object Has No Attribute ‘Items’ Error In Python

Once you hit this attributeerror: ‘list’ object has no attribute ‘items’, the goal is to confirm what kind of object you have at that point in your code. That removes guesswork and shows exactly where your mental model of the data differs from reality.

• Print The Type — Add a temporary print(type(data)) or log statement before the failing line so you can see whether data is list, dict, or something else.
• Inspect A Sample Value — Print a slice such as data[0] or data[0:3] when data is a list so you can see what each entry contains.
• Use The Debugger — Run the code under pdb or an IDE debugger, stop just before the failing line, and inspect the variable in the watch window.
• Check The Upstream Call — Read the docstring or help output for the function that produces the value. Confirm whether it states list, dict, or list of dicts.

Once you know what structure you have, you can adjust either the code that builds that structure or the part that consumes it. The fixes fall into a few clear groups, depending on whether you want to keep a list, keep a dictionary, or switch from one to the other.

Many engineers keep a short checklist for attribute errors. Step one is always verify the type. Step two is compare the method you called with the methods that type actually offers, often with dir(obj) or quick searches in the standard library docs. That small routine moves you from guessing to deliberate debugging.

Fixing AttributeError: ‘List’ Object Has No Attribute ‘Items’ Step By Step

Here are the most common correction paths when you run into this error message in your own code.

When You Meant To Loop Over A Dictionary

If your variable should be a single dictionary but ends up as a list, you often just need to select the right element.

• Index Into The List — Change for name, value in data.items(): to for name, value in data[0].items(): when data is a list with one dictionary element.
• Pick The Right Position — When data holds several dictionaries, choose the one you need, such as data[1] or data[-1], and loop over that object instead.
• Flatten Several Dictionaries — If you want to loop through each dictionary in a list, use nested loops that handle one dictionary at a time.

In real data you often have lists that wrap a single mapping because some library keeps space for more entries later. In that situation, indexing at position zero is fine as long as you guard against an empty list. When several mapping objects live in the same list, nested loops give you steady control over order and let you combine or filter values as you go.

Here is a small snippet that shows how to turn a list of dictionaries into one flat list of items without calling items() on the list itself.

records = [
    {"id": 1, "name": "Ada"},
    {"id": 2, "name": "Linus"},
]

pairs = []
for record in records:
    for name, value in record.items():
        pairs.append((name, value))

When The List Is The Right Shape

Sometimes the data truly belongs in a list, so the fix is to stop reaching for items() and use list features instead.

• Loop Directly Over Values — Write for value in data: when you only need each element, not a separate index and a value.
• Use enumerate For Index And Value — When you also want the position, write for index, value in enumerate(data): and drop items() completely.
• Build A New List With Comprehension — Use [process(x) for x in data] to transform each entry, again with no call to items().

By leaning on list tools in these cases, you keep the source data honest and remove the mismatch that led to the error message in the first place.

Code that treats a list as a list is easier to read for the next person. When someone sees for value in data they know at once that order may matter and that duplicates are allowed. That small bit of clarity reduces false assumptions about hidden names or lookups.

When You Need A Dictionary Instead Of A List

In some designs you really do need named values. In that case your options revolve around turning the list into a dictionary at the right step.

• Convert A List Of Pairs To A Dict — If data looks like [(“a”, 1), (“b”, 2)], you can call dict(data) to get {“a”: 1, “b”: 2}, then use items().
• Build A Dict In A Loop — Start with result = {} and fill it inside a loop over the list, setting result[name] = value.
• Use Dictionary Comprehension — Write {name: value for name, value in data} when the list already holds suitable two item tuples.

After that conversion, calling items() makes sense again because you now hold a dictionary with named fields instead of a bare list of values.

When you convert lists to dictionaries, watch out for repeated names. If two pairs share the same name, the later one replaces the earlier one. That behavior can be useful when you want last win rules, yet it can also hide input problems, so add tests when the source data might repeat names by mistake.

How To Prevent This AttributeError In New Code

Once you have patched the current bug, a little structure in your coding habits can stop the same attributeerror from coming back in later refactors.

• Name Variables By Shape — Use names like user_list, user_dict, or rows_by_id so that the variable name always hints at its layout.
• Store Types In Docstrings — When you write helper functions, mention whether they return list, dict, or list of dicts right in the docstring.
• Add Type Hints — Use hints such as def load_users() -> list[dict[str, str]]: and let a type checker alert you when you misuse the result.
• Write Small Tests — Add tests that load data from real sources and assert the type and sample content of every main structure.

These small habits add clarity to the code base and save you time when you come back months later and no longer remember exactly which helper returned a list and which returned a dictionary.

Static type checkers such as mypy or pyright fit well into this habit. They read your type hints and flag calls where a list method is used on a dictionary or the other way round. Running them as part of continuous integration keeps this class of bug from reaching production code in the first place.

Quick Reference Table For Lists, Dicts, And items()

This table gives you a compact reminder of when items() works and how to loop when you see list or dict in your code.

A handy way to use this table is during a traceback review. Take the variable name from the failing line, match it to the row here, and check whether the loop that uses it matches the pattern in the third column. If not, you have a strong hint that either the data type or the loop structure needs adjustment. You can even copy the pattern directly into your code editor or notebook.

Keep this distinction in mind when reading error messages. When you see this message in a traceback, look for the line that called items(), confirm whether your variable actually holds a dictionary, and then bring the code and the data back into alignment.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback