Types, Values, and Errors in Python

Want to understand types, values, and errors in Python? Every piece of data you write has both a value (what it is) and a type (what kind of thing it is). Miss either one, and you get bugs — some loud, some silent.

This page is the mental model before variables and operators: what Python sees when you type a number or a word, how to ask with type(), and how syntax, runtime, and semantic errors differ when things go wrong.

What you will learn

By the end you can:

• Explain what a value is vs what a type is
• Use type() to inspect int, float, and str
• Spot when quotes turn a “number” into text
• Avoid the 1,000,000 comma trap (a classic semantic error)
• Tell syntax, runtime, and semantic errors apart
• Treat silent wrong answers as the most dangerous class of bug

We are not covering variables, assignment, or full data-structure types yet. This page is how Python classifies the small pieces you type — and how it fails when the classification or the meaning is wrong.

Values and types — every piece of data has an identity

When you first talk to Python, you start with simple things — numbers and words:

1
2
"hello"

Python understands each of these. Quietly, though, it is doing something important: it is classifying everything you say.

A value is one of the most basic things in a program — a concrete piece of data. 2 is a value. "Hello, World!" is a value.

Python does not only care what the value is. It also cares what kind of thing it is:

• 2 arrives as a number
• "Hello, World!" arrives as text

Those identities are called types. The type decides which operations make sense later — you can add two numbers; you cannot divide a word by another word and expect a normal result.

Ask Python with type()

If you are unsure what Python thinks a value is, ask it:

type("hello, world")
# <class 'str'>

type(17)
# <class 'int'>

A pattern forms quickly:

• Text inside quotes → str (string)
• Whole numbers → int (integer)

Then you type a number with a decimal point:

type(17.5)
# <class 'float'>

Why float? Decimal numbers are stored with floating-point representation — they are not fixed whole units like integers; the decimal point can “float” in how the number is represented.

Quotes change the type

Appearances lie. Try this:

type("17")
# <class 'str'>

It looks like a number. Quotation marks still win. Inside quotes, Python treats it as text, not a number. That single detail causes countless beginner bugs when you later try to do math on user input that arrived as a string.

A quiet mistake: writing 1,000,000

You want one million. You instinctively write commas the way you would on paper:

1,000,000

Python does not complain. No red text. No crash. It calmly gives you something like:

(1, 0, 0)

It did not see one million. It saw three separate integers, separated by commas (a tuple). You meant one value; you wrote three.

This is a classic semantic error: the program is legal, it runs, and the meaning is still wrong. Write one million as 1000000 or 1_000_000 (underscores are allowed as digit separators in modern Python).

Three kinds of errors

Sometimes Python refuses to listen. Sometimes it listens, then crashes halfway. Sometimes — the worst case — it listens, runs, and quietly betrays your intention.

Those failures are all “errors,” but they are not the same kind of failure. (For how interpreters surface errors while running, see Programs, Interpreters & Compilers.)

Syntax errors — the language rules are broken

A syntax error means Python cannot even parse what you wrote. The structure of the language is broken — missing quotes, unbalanced parentheses, illegal indentation.

print("hello
# SyntaxError: unterminated string literal

Think of it like broken grammar in English: the listener cannot decide what the sentence was supposed to be. Python never starts running the rest of the program until the syntax is fixed.

Runtime errors — legal code that fails while running

A runtime error (often called an exception) means the grammar was fine, but something went wrong during execution.

print(10 / 0)
# ZeroDivisionError: division by zero

Python understood the instruction. It started running. Then it hit an impossible situation.

x = 10
print(y)
# NameError: name 'y' is not defined

You asked for a name that does not exist yet. Runtime errors are accidents during execution — not before.

Semantic errors — runs fine, meaning is wrong

A semantic error (a logic bug) is the most dangerous class for beginners. The program is legal. It finishes. There is no traceback. The idea was wrong.

The 1,000,000 example is one. Here is another:

minutes = 60
hours = minutes / 24
print(hours)
# 2.5  — runs, but the formula is wrong (should be / 60)

Perfect “grammar.” Wrong meaning. Python did exactly what you wrote — not what you intended.

Error types at a glance

Rule of thumb: if Python refuses to read your sentence, fix the grammar. If it crashes mid-run, fix the situation. If it smiles and gives the wrong answer — fix your thinking.

Putting it together in a few lines

A short interactive-style session that checks types and avoids the comma trap:

print(type(17))        # <class 'int'>
print(type(17.5))      # <class 'float'>
print(type("17"))      # <class 'str'>  — quotes win

million = 1_000_000    # one million (not a tuple)
print(million)
print(type(million))   # <class 'int'>

Common mistakes

• Assuming "17" is a number — quotes make it a str
• Writing 1,000,000 for one million — that is three values, not one
• Ignoring type() when debugging surprising behavior
• Treating every crash the same — syntax vs runtime need different fixes
• Trusting a program that “runs with no errors” — semantic bugs leave no traceback
• Memorizing type names without typing a few examples in interactive mode