Python range() Explained: Stop Writing Broken Loops Forever

The off-by-one error killed a batch job at a fintech I consulted for — 99,999 records processed instead of 100,000, one customer's end-of-month statement never generated, and nobody noticed for six weeks because the count was 'close enough' to pass the eyeball test. The culprit was a misunderstood range() call. One wrong number. Six weeks of silent wrong data.

range() is the engine behind almost every loop you write in Python. Get it wrong and your loops silently skip data, process one record too many, or run forever. Get it right and you have precise, memory-efficient control over iteration that scales from five items to five billion without changing a single line of logic. This isn't academic — every data pipeline, every retry loop, every pagination handler in Python touches range().

By the end of this, you'll know exactly how range() works under the hood, why it doesn't store numbers in memory, how to count backwards without a hacky workaround, and the three specific mistakes that cause silent data corruption in production loops. You'll write range() calls with confidence and spot broken ones in code review on sight.

What range() Actually Is (And Why It's Not a List)

Before range() existed in its modern form, Python 2 had a function called range() that returned an actual list and a separate function called xrange() that returned a lazy iterator. Developers who needed to loop a million times with the old range() would inadvertently build a list of a million integers in memory just to count — pure waste. Python 3 collapsed them: range() is now always lazy. It never builds the full list. It just remembers three numbers — start, stop, step — and calculates each value on demand.

This matters the moment you're paginating through a database result set, iterating over file offsets, or running a retry loop in a distributed system. You're not paying memory cost for the count — you're paying only for the current position.

Think of range() as a bookmark rule, not a bookshelf. 'Start at page 10, read every third page, stop before page 40' — you don't photocopy those pages in advance. You just follow the rule as you go. That's the exact mental model. range() is the rule. The loop is you following it.

# io.thecodeforge — Python tutorial

import sys

# A list of 1 million integers — Python builds every single number in memory right now
million_list = list(range(1_000_000))

# A range object covering the same 1 million numbers — stores only start, stop, step
million_range = range(1_000_000)

# See the memory difference for yourself
list_size_bytes = sys.getsizeof(million_list)
range_size_bytes = sys.getsizeof(million_range)

print(f"list of 1,000,000 ints : {list_size_bytes:,} bytes")
print(f"range(1,000,000)       : {range_size_bytes} bytes")

# range() is a sequence type — you can index it, slice it, check membership
page_offsets = range(0, 10_000, 250)  # database pagination: start=0, stop=10000, step=250

print(f"\nFirst page offset  : {page_offsets[0]}")
print(f"Second page offset : {page_offsets[1]}")
print(f"Last page offset   : {page_offsets[-1]}")
print(f"Total pages        : {len(page_offsets)}")
print(f"Is offset 500 valid page start? {500 in page_offsets}")
print(f"Is offset 501 valid page start? {501 in page_offsets}")

The Three-Argument Syntax: Start, Stop, Step Without Guessing

Every range() confusion in the wild traces back to one of two things: forgetting that stop is exclusive, or not knowing that step exists. Here's the full syntax once and for all: range(start, stop, step). Start is where counting begins. Stop is where counting ends — but the stop value itself is never included. Step is how much to add each time.

When you write range(5), Python treats it as range(0, 5, 1) — start defaults to 0, step defaults to 1. That's why range(5) gives you 0, 1, 2, 3, 4 — five values, none of them 5. This isn't arbitrary. It means range(len(my_list)) always gives you exactly the valid indices for that list. No off-by-one. By design.

The step argument is where range() earns its keep beyond toy loops. Batch processing every Nth record, building retry delays that increase by a fixed interval, checking every even-numbered port in a range — these all need step. And for counting backwards, you use a negative step. There's no reverse() call needed, no subtraction gymnastics. Just a negative number.

# io.thecodeforge — Python tutorial

# --- Scenario: A payment processor retry scheduler ---
# We need to retry a failed charge at increasing intervals.
# Retry at seconds: 5, 10, 15, 20, 25 (linear backoff, max 5 retries)

MAX_RETRIES = 5
BASE_DELAY_SECONDS = 5

print("=== Linear Backoff Retry Schedule ===")
for attempt_number in range(1, MAX_RETRIES + 1):  # range(1, 6) — gives 1,2,3,4,5
    delay = attempt_number * BASE_DELAY_SECONDS
    print(f"Attempt {attempt_number}: retry after {delay}s")

# --- Scenario: Processing a leaderboard in reverse rank order ---
# Display rank 10 down to rank 1 (countdown-style)

print("\n=== Leaderboard Countdown ===")
for rank in range(10, 0, -1):  # start=10, stop=0 (exclusive), step=-1
    print(f"Rank #{rank}")

# --- Scenario: Batch database writes, 100 records at a time ---
TOTAL_RECORDS = 450
BATCH_SIZE = 100

print("\n=== Batch Write Boundaries ===")
for batch_start in range(0, TOTAL_RECORDS, BATCH_SIZE):  # 0, 100, 200, 300, 400
    # min() prevents overshooting on the final partial batch
    batch_end = min(batch_start + BATCH_SIZE, TOTAL_RECORDS)
    print(f"Writing records {batch_start} to {batch_end - 1}")

# --- Demonstrating stop is ALWAYS exclusive ---
print("\n=== Stop Is Exclusive — Always ===")
print(f"range(0, 5)    → {list(range(0, 5))}")    # 5 is never included
print(f"range(1, 6)    → {list(range(1, 6))}")    # useful when you want 1-5
print(f"range(5, 0, -1)→ {list(range(5, 0, -1))}") # counts down but stops before 0

Off-By-One Errors: The Exact Bug Pattern That Corrupts Production Data

Off-by-one errors with range() are insidious because the code runs — no exception, no crash, no obvious failure. You just silently process one record too few or too many. The fintech story I opened with? Exactly this. A developer wrote range(1, record_count) when they meant range(0, record_count). Record at index 0 never processed. Six weeks of silent corruption.

There are exactly three failure modes to memorise. First: range(1, n) when you mean range(0, n) — skips the first item. Second: range(0, n-1) when you mean range(0, n) — skips the last item. Third: range(0, n+1) when you mean range(0, n) — processes one item past the end, usually causing an IndexError or processing a sentinel value as real data.

The rule that prevents all three: when iterating a list or array by index, always use range(len(collection)). No manual arithmetic on the stop value. When iterating a count of things (do this 10 times), use range(10). When you need 1-based counting (item 1, item 2...), use enumerate(collection, start=1).

# io.thecodeforge — Python tutorial

# --- Real scenario: processing customer invoice line items ---
invoice_items = [
    {"sku": "WIDGET-A", "qty": 3, "unit_price": 9.99},
    {"sku": "GADGET-B", "qty": 1, "unit_price": 49.99},
    {"sku": "DOOHICKEY-C", "qty": 5, "unit_price": 4.50},
]

item_count = len(invoice_items)  # 3

print("=== BUG: range(1, item_count) — skips the first item ===")
for i in range(1, item_count):  # gives indices 1, 2 — index 0 (WIDGET-A) is GONE
    item = invoice_items[i]
    print(f"  Processing: {item['sku']}")
# WIDGET-A never billed. Silent revenue loss.

print("\n=== BUG: range(0, item_count - 1) — skips the last item ===")
for i in range(0, item_count - 1):  # gives indices 0, 1 — index 2 (DOOHICKEY-C) is GONE
    item = invoice_items[i]
    print(f"  Processing: {item['sku']}")
# DOOHICKEY-C never billed. More silent revenue loss.

print("\n=== CORRECT: range(len(invoice_items)) — processes every item ===")
for i in range(len(invoice_items)):  # gives indices 0, 1, 2 — all items hit
    item = invoice_items[i]
    print(f"  Processing: {item['sku']}")

print("\n=== BETTER: enumerate() when you need index AND value ===")
for line_number, item in enumerate(invoice_items, start=1):  # 1-based line numbers
    subtotal = item['qty'] * item['unit_price']
    print(f"  Line {line_number}: {item['sku']} — ${subtotal:.2f}")

range() vs enumerate() vs zip(): Picking the Right Tool Every Time

range() is not always the right tool for looping — and using it when you shouldn't is a tell that someone learned Python through C. Here's the decision tree you should have hardwired.

Use range(n) when you need a bare count: run this loop exactly n times, generate n evenly-spaced values, or you genuinely only need the index with no corresponding data. Use range(len(collection)) only when you need to modify the list in-place by index — inserting at a position, swapping elements, or accessing two lists simultaneously by the same index. The moment you're writing collection[i] just to read a value, switch to a direct for item in collection loop. Use enumerate(collection) when you need both the position and the value — building numbered output, tracking progress through a list, logging which item failed. Use zip(list_a, list_b) when you need to walk two sequences in lockstep — pairing up input records with expected outputs, merging two data streams.

These aren't stylistic preferences. range(len(x)) where a direct loop would do is harder to read, introduces off-by-one risk, and gets flagged in every serious Python linter.

# io.thecodeforge — Python tutorial

order_ids = ["ORD-001", "ORD-002", "ORD-003", "ORD-004"]
order_statuses = ["shipped", "pending", "cancelled", "shipped"]

# --- range(n): pure count loop — send N reminder emails ---
print("=== range(n): run exactly N times ===")
for reminder_number in range(3):  # 0, 1, 2 — we don't care about index meaning
    print(f"Sending scheduled reminder #{reminder_number + 1}")

# --- Direct iteration: read each item — no index needed ---
print("\n=== Direct for-in: cleanest when index is irrelevant ===")
for order_id in order_ids:
    print(f"Dispatching notification for {order_id}")

# --- enumerate(): need position AND value — building an audit log ---
print("\n=== enumerate(): index + value together ===")
for position, order_id in enumerate(order_ids, start=1):
    print(f"Audit entry {position}: processed {order_id}")

# --- zip(): two sequences in lockstep — pairing orders with statuses ---
print("\n=== zip(): walking two lists together ===")
for order_id, status in zip(order_ids, order_statuses):
    print(f"{order_id} → {status}")

# --- range(len(x)): legitimate use — in-place list modification ---
print("\n=== range(len(x)): in-place update (valid use case) ===")
priority_scores = [72, 45, 91, 38]
for i in range(len(priority_scores)):  # need index to WRITE back to the list
    if priority_scores[i] < 50:
        priority_scores[i] = 0  # zero out low-priority scores
print(f"Adjusted scores: {priority_scores}")

Frequently Asked Questions