Python ValueError (tested)

ValueError is Python's catch-all for "the type is right, but the value itself is unacceptable here." That's what separates it from TypeError (wrong type entirely): int("abc") gets a string, which int() accepts in general, but "abc" specifically can't be parsed as a number. We reproduced eight distinct, common ValueError cases to show how differently they're worded depending on what failed.

1. Eight reproduced cases

Every one of these passed a value of the correct type (a string to int(), a list to unpack, a number to sqrt()) that was nonetheless invalid for that specific call. That's the dividing line from TypeError, which is reserved for passing the wrong type entirely (like int(None) or len(5)).

2. Parsing strings: int() and float()

int("12.5") fails — not because 12.5 isn't a number, but because int() parses whole-number literals only, not decimal syntax. The message quotes the exact string that failed, which is useful when the bad value came from user input or a parsed file:

>>> int("12.5")
ValueError: invalid literal for int() with base 10: '12.5'
>>> float("12.5")   # works fine
12.5

Fix: use float() first then int(float(s)) if truncating a decimal string is intended, or validate the input format before parsing (e.g. s.isdigit() for a simpler but less complete check, or a try/except ValueError around the parse).

3. math domain error: value outside the function's valid range

math.sqrt(-1) raises because the math module only works with real numbers, and the square root of a negative number isn't real. This is a distinct case from parsing — the input is a perfectly good int, just mathematically invalid for this function:

>>> import math
>>> math.sqrt(-1)
ValueError: math domain error

Fix: validate the domain before calling (if n >= 0: math.sqrt(n)), or use the cmath module (cmath.sqrt(-1) returns a complex number, 1j, instead of raising) if complex results are actually wanted.

4. Unpacking mismatches: the count has to match exactly

Tuple/list unpacking requires the left side to have exactly as many names as the right side has values — no more, no fewer:

>>> a, b = [1, 2, 3]
ValueError: too many values to unpack (expected 2)
>>> a, b, c = [1, 2]
ValueError: not enough values to unpack (expected 3, got 2)

Fix: use the star-unpack syntax when the extra values should be collected rather than rejected: a, b, *rest = [1, 2, 3, 4] puts [3, 4] in rest instead of raising.

5. "Not found" errors: index() raises, find() doesn't

Python has two different conventions for "search and report absence" depending on the method:

>>> "hello".index("z")
ValueError: substring not found
>>> "hello".find("z")      # returns -1 instead, no exception
-1
>>> [1,2,3].remove(9)
ValueError: list.remove(x): x not in list

Fix: use str.find() (returns -1) instead of str.index() when "not found" is an expected, normal outcome you want to check with an if. For lists, check if 9 in my_list: before .remove(), since lists have no non-raising equivalent of remove().

6. Fix checklist

• Wrap parsing (int(), float(), datetime.strptime()) in try/except ValueError whenever the input comes from a user, file, or external API — it will eventually be malformed.
• For math functions, validate the domain before calling, or use the cmath/alternate module if out-of-domain inputs should produce a result instead of an error.
• For unpacking a variable-length sequence, use star-unpacking (a, *rest = seq) instead of a fixed count of names.
• Prefer the non-raising sibling method (find() over index(), in checks before remove()) when "not found" is a normal case, not a bug.

If the value is missing entirely (None) rather than merely invalid, that's AttributeError or TypeError territory instead, not ValueError.

Written with AI assistance. Measured on 2026-10-03 with Python 3.13.5 on Linux using plain python3 one-liners. Every error below is copy-pasted output, not paraphrased. PlainHeaders is our extension; Python is free.