
Python has three built-in numeric types: `int` (arbitrary precision - no overflow), `float` (IEEE 754 double), and `complex`. The standard library adds `decimal.Decimal` for exact decimal arithmetic and `fractions.Fraction` for rational numbers.

<ExamplePair>
<ExampleProse>

`int` in Python has no fixed size, so it never overflows. Integer division uses `//`, the remainder operator is `%`, and `pow(base, exp, mod)` computes modular exponentiation efficiently without building a huge intermediate number.

</ExampleProse>
<ExampleCode>

```python
2 ** 100          # 1267650600228229401496703205376 - exact, no overflow

10 // 3           # 3  (integer division, rounds toward negative infinity)
10 % 3            # 1  (remainder)

pow(2, 10, 1000)  # 24  (2**10 mod 1000, fast even for huge exponents)
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`float` uses IEEE 754 binary representation, which cannot represent most decimal fractions exactly. The classic example: `0.1 + 0.2` is not `0.3`. Use `math.isclose(a, b)` when comparing floats by tolerance rather than exact equality.

</ExampleProse>
<ExampleCode>

```python
import math

0.1 + 0.2           # 0.30000000000000004
0.1 + 0.2 == 0.3    # False

math.isclose(0.1 + 0.2, 0.3)           # True  (relative tolerance 1e-9)
math.isclose(0.1 + 0.2, 0.3, rel_tol=1e-6)  # True
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`decimal.Decimal` stores numbers as exact decimal fractions - the same way humans write them. This makes it the right choice for money and accounting, where rounding rules matter. Pass values as strings to avoid inheriting float imprecision at construction time.

</ExampleProse>
<ExampleCode>

```python
from decimal import Decimal, ROUND_HALF_EVEN, getcontext

Decimal("0.1") + Decimal("0.2")   # Decimal('0.3')  - exact

# Set rounding mode for the current thread's context
getcontext().rounding = ROUND_HALF_EVEN

price = Decimal("19.995")
price.quantize(Decimal("0.01"))   # Decimal('20.00')  - banker's rounding
```

</ExampleCode>
</ExamplePair>

<InProduction>
Never store monetary values as `float` - `0.1 + 0.2 != 0.3` ships production bugs that staging never catches; use `decimal.Decimal` with an explicit rounding mode (`ROUND_HALF_EVEN` for accounting). The small-integer interning trap means `a is b` returns `True` for integers in roughly -5 to 256 but `False` for larger values; always use `==` for numeric value comparison.
</InProduction>


Python's three numeric types: int (arbitrary precision), float (IEEE 754), and complex - plus Decimal for exact arithmetic.

Numbers


A Python `str` is an immutable sequence of Unicode code points - not bytes. The separate `bytes` type holds raw binary data. Converting between them requires an explicit `.encode()` call (str to bytes) or `.decode()` call (bytes to str), and you must name the encoding each time.

<ExamplePair>
<ExampleProse>

f-strings (formatted string literals) embed expressions directly inside `{}`. They support Python's full format-spec syntax for alignment, padding, and number formatting - the same spec used by `format()` and `str.format()`.

</ExampleProse>
<ExampleCode>

```python
name = "Ada"
f"Hello, {name}!"         # 'Hello, Ada!'

value = 3.14159
f"{value:.2f}"            # '3.14'  (2 decimal places)

n = 42
f"{n:>10}"                # '        42'  (right-aligned in 10 chars)
f"{n:0>10}"               # '0000000042'  (zero-padded)
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`str` and `bytes` are separate types and Python never converts between them automatically. `.encode(encoding)` produces `bytes`; `.decode(encoding)` produces `str`. If the bytes do not match the encoding you name, Python raises `UnicodeDecodeError` - pass `errors="replace"` to substitute replacement characters instead of crashing.

</ExampleProse>
<ExampleCode>

```python
s = "héllo"
b = s.encode("utf-8")       # b'h\xc3\xa9llo'  (5 chars -> 6 bytes)

b.decode("utf-8")            # 'héllo'

# Wrong codec raises UnicodeDecodeError
b.decode("ascii")            # UnicodeDecodeError: invalid start byte

# Safety valve: replace undecodable bytes with the replacement character
b.decode("ascii", errors="replace")   # 'h��llo'
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`len(s)` counts Unicode code points, not characters as humans perceive them (graphemes). A single visible character can be multiple code points when combining marks are used - for example, the letter `a` followed by a combining accent. Naive slicing can split a grapheme in the middle. Normalising with `unicodedata.normalize("NFC", s)` folds as many combining sequences as possible into single composed code points before slicing or comparing.

</ExampleProse>
<ExampleCode>

```python
import unicodedata

# 'a' + combining acute accent = two code points, one visible character
composed = "á"          # á  (precomposed, 1 code point)
decomposed = "á"       # a + combining acute, 2 code points

len(composed)                # 1
len(decomposed)              # 2

# Normalize to NFC before comparing or slicing user input
unicodedata.normalize("NFC", decomposed) == composed   # True
```

</ExampleCode>
</ExamplePair>

<InProduction>
f-strings evaluate arbitrary expressions inside `{...}` - never format untrusted input as if it were a template string; use `str.format_map` with a restricted mapping, or better, keep user input as data rather than embedding it in format strings. `len(s)` counts code points, not graphemes - naive slicing of user input with emoji or combining marks produces mojibake; normalise with `unicodedata.normalize("NFC", s)` or reach for the `regex` package before truncating display strings.
</InProduction>


Python str is an immutable sequence of Unicode code points, not bytes. Encoding, f-strings, and grapheme-aware slicing.

Strings


Variables in Python are name bindings, not declarations. An assignment `x = 1` creates a name `x` that points to the integer `1`; re-assigning `x = 2` rebinds the name to a different object. The original object is unchanged, and Python's garbage collector reclaims it if no other names point to it.

<ExamplePair>
<ExampleProse>

Simple assignment, multiple assignment on one line, and in-place swap all work without a temporary variable.

</ExampleProse>
<ExampleCode>

```python
x = 10
a, b = 1, 2        # multiple assignment
a, b = b, a        # swap without a temp variable

print(a, b)        # 2 1
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

When a function reads a variable, Python searches scopes in LEGB order: Local, Enclosing, Global, Built-in. A function can read an outer variable without any extra keyword.

</ExampleProse>
<ExampleCode>

```python
x = "global"

def show():
    print(x)   # reads the global x - no keyword needed

show()         # global
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

The `UnboundLocalError` trap: if a function assigns to a name anywhere in its body, Python treats that name as local for the *entire* function, even before the assignment line. Reading it before the assignment raises `UnboundLocalError`. Use `nonlocal` (for a name in an enclosing function) or `global` (for a module-level name) when a rebinding is intentional.

</ExampleProse>
<ExampleCode>

```python
count = 0

def broken():
    print(count)  # UnboundLocalError! assignment below makes count local
    count = count + 1

def fixed():
    global count
    print(count)  # 0 - now unambiguously the global
    count = count + 1
```

</ExampleCode>
</ExamplePair>

<InProduction>
Python rebinds names; it does not declare them. A function that assigns to `x` shadows any outer `x` for the entire function body, even before the assignment line - reading it earlier raises `UnboundLocalError`. Reach for `nonlocal` only when closure state genuinely belongs to the enclosing function; class state belongs on `self`.
</InProduction>


Variables in Python are name bindings. Understand multiple assignment, LEGB scope, and the UnboundLocalError trap.