TypeError —
Python won't silently guess what you meant.
You tried an operation between two types that Python doesn't know how to combine — most commonly a string and a number. Unlike some languages, Python never auto-converts types to make an operation "work" — it stops and tells you exactly which two types collided. Watch the type mismatch happen at the exact operation on LearnBug.
What is TypeError: unsupported operand type?
Python raises this when an operator (like +, -, *) is applied to two types that don't define how to combine with each other — most commonly trying to add a string and an integer. Python never implicitly converts one type to the other; you must convert explicitly.
Why visualization helps
The traceback tells you the line, but not always why a variable ended up the "wrong" type in the first place — especially when it came from input(), a function's return value, or user data. LearnBug shows each variable's actual type at every step, so you can see exactly where a number quietly became a string.
Three ways two incompatible types meet
input() always returns a string
Every value from input() is a string, even if the user types a number — using it in math directly without converting first is the single most common cause.
A function that sometimes returns None
Using a value from a function that can return None (e.g. dict.get() on a missing key) in an operation that expects a number crashes only when that None path is hit.
Mixed types from external data
Data from a file, API response, or CSV often arrives as strings even for numeric fields — mixing it with real numbers in your own code triggers the same error.
age = input(...); age + 1
User types "25" — input() returns the string "25", not the integer 25
This is true no matter what the user types — even purely numeric input comes back as str. Python has no way to know the "intent" was a number.
age + 1 tries to add a str and an int — Python checks if that's defined
Python's + operator has different meanings for different types (concatenation for strings, addition for numbers) — but no meaning at all is defined between a string and an integer.
No implicit conversion happens — Python raises TypeError immediately
Unlike some languages that would silently convert one type to match the other, Python refuses to guess and raises an error right at this specific operation.
Result: TypeError: can only concatenate str (not "int") to str ✗
The broken code, and the traceback it produces
age = input("Enter your age: ") # always a string, e.g. "25"
next_year = age + 1
print(next_year)Enter your age: 25
Traceback (most recent call last):
File "age.py", line 2, in <module>
next_year = age + 1
~~~~^~~
TypeError: can only concatenate str (not "int") to strConvert explicitly with int()
age = int(input("Enter your age: ")) # convert to int right away
next_year = age + 1
print(next_year) # 26Quick Reference
Frequently asked questions
Why doesn't Python just auto-convert the string to a number?
Because it can't safely guess your intent in every case — "25" clearly converts to a number, but "twenty-five" or an empty string don't, and silently guessing wrong would produce confusing bugs instead of a clear error. Requiring an explicit conversion makes the programmer's intent unambiguous.
What if the user types something that isn't a valid number?
int("twenty-five") raises a different error — ValueError: invalid literal for int() — since the conversion itself fails, not the later arithmetic. See the ValueError guide for handling that case, typically with a try/except around the conversion.
Does this happen with other operators besides +?
Yes — any operator (-, *, /, comparisons like <) between incompatible types raises the same class of TypeError, with a message naming the specific operator and the two types involved. The fix is always the same: convert one side to match the other before the operation.
How do I avoid this when I'm not sure what type a variable will be?
Add a defensive check or conversion at the boundary where the value enters your code — right after input(), right after reading a file, right after an API call — rather than deep inside logic that assumes a specific type. Catching the mismatch early produces a clearer error location than letting it surface wherever the value happens to get used.
Watch a value's type at every step
Paste your code into LearnBug and see exactly which two types collided.