Python range() — range(1, n) Skips Index 0 Silently

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 nightly billing accumulation never updated, and nobody noticed for six weeks because the total count was close enough to pass the eyeball test. No exception was raised. No alert fired. The job logged 'success' every single night. The culprit was a misunderstood range() call. One wrong number in the start argument. 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 with no complaint. 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 is not academic — every data pipeline, every retry loop, every pagination handler, every batch processor in Python touches range().

By the end of this guide you will know exactly how range() works under the hood, why it does not store numbers in memory, how to count backwards without any workaround, how membership testing in range() is O(1) when list scanning is O(n), and the specific mistake patterns that cause silent data corruption in production loops. You will write range() calls with confidence and spot broken ones in code review on sight.

All code examples and memory figures in this article were verified on CPython 3.12. The sys.getsizeof values you see reflect CPython's internal representation for that version — results will differ slightly on Python 3.10 or 3.11, and will differ more substantially on PyPy or Jython. The algorithmic properties — O(1) membership testing, lazy evaluation, 48-byte range object size — hold across all CPython versions from 3.2 onwards.

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

Before range() existed in its modern form, Python 2 had two functions: range() that returned an actual list and 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 drive the iteration — pure overhead with no payoff. Python 3 collapsed them: range() is now always lazy. It never builds the full list. It stores exactly three integers — start, stop, step — and calculates each value on demand as the loop advances.

This matters the moment you are paginating through a database result set, iterating over file offsets, or running a retry loop in a distributed system where worker memory is constrained. You are not paying a memory cost proportional to the count — you are paying for three integers, always, regardless of whether the range covers five numbers or five billion.

One important precision that most articles skip: sys.getsizeof() on a list returns the shallow size — the size of the container and its array of pointers to integer objects, but not the integer objects themselves. For list(range(1_000_000)), sys.getsizeof() reports roughly 8MB. But CPython allocates heap memory for every integer outside the small-integer cache (-5 to 256). The 999,744 integers from 257 to 999,999 each occupy roughly 28 bytes, adding approximately 27MB to the true footprint. Total real allocation: closer to 35MB, not 8MB. The range() object stays at 48 bytes regardless, because it stores three Python integers — all of which fall in the cached range or cost negligible overhead. The memory efficiency argument for range() is even stronger than the shallow-size comparison suggests.

The implementation detail that surprises most developers: range() is not just an iterator. It is a full sequence type. You can index into it directly (range(10)[7] == 7), slice it (range(0, 100, 2)[3:6] returns a new range object), get its length in constant time (len(range(100)) == 100), and test membership in O(1). That last property has a behaviour almost nobody learns until an interview forces it. Membership testing in a range() object applies an arithmetic formula: is the value an integer, does (value - start) % step == 0, and does the value fall within the [start, stop) bounds? Three constant-time calculations. It never iterates through the range to check. A list scan is O(n) and gets slower as the list grows; a range membership check takes the same time whether the range has 10 elements or 10 billion.

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

# io.thecodeforge — Python tutorial
# Verified on CPython 3.12

import sys
import tracemalloc
import time

# ── Shallow vs true memory comparison ─────────────────────────────────────────
# sys.getsizeof() returns the SHALLOW size — the container and its pointer array.
# It does not include the memory consumed by the integer objects themselves.
# tracemalloc captures the true peak allocation including all object creation.

print("=== Shallow size (sys.getsizeof) ===")
million_range = range(1_000_000)
print(f"range(1_000_000)       : {sys.getsizeof(million_range):>12,} bytes (3 integers — start, stop, step)")

# Measure true allocation of list(range(1_000_000)) using tracemalloc
tracemalloc.start()
million_list = list(range(1_000_000))
_, peak_bytes = tracemalloc.get_traced_memory()
tracemalloc.stop()

shallow_bytes = sys.getsizeof(million_list)
print(f"list shallow size      : {shallow_bytes:>12,} bytes (pointer array only)")
print(f"list true peak alloc   : {peak_bytes:>12,} bytes (includes all integer objects)")
print(f"True memory ratio      : {peak_bytes // sys.getsizeof(million_range):,}x")
# True ratio is roughly 700,000x — far more than the shallow 166,667x suggests
# because integers above 256 are heap-allocated objects, not just pointer slots

# ── range() is a full sequence type ────────────────────────────────────────────
print("\n=== range() sequence capabilities ===")
page_offsets = range(0, 10_000, 250)  # database pagination rule: 40 pages of 250

print(f"First 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"Slice [1:4]        : {list(page_offsets[1:4])}")

# ── O(1) membership testing — equal-size comparison ─────────────────────────
# Both collections cover the same 5,000 even numbers.
# The algorithmic difference is structural, not scale-dependent.
print("\n=== Membership testing: range() vs list() — equal size ===")
SIZE = 5_000
big_range = range(0, SIZE * 2, 2)           # even numbers 0 to 9998 — 5,000 elements
big_list  = list(range(0, SIZE * 2, 2))     # same 5,000 even numbers as a list

target_present = SIZE * 2 - 2               # last element — worst case for list scan
target_absent  = SIZE * 2 - 1              # odd number — not in either collection

# range(): O(1) — arithmetic formula regardless of where the target sits
trials = 100_000
start = time.perf_counter_ns()
for _ in range(trials):
    _ = target_present in big_range
range_ns = (time.perf_counter_ns() - start) // trials

# list(): O(n) — scans from index 0, worst case visits all 5,000 elements
start = time.perf_counter_ns()
for _ in range(trials):
    _ = target_present in big_list
list_ns = (time.perf_counter_ns() - start) // trials

print(f"range membership (5K even nums, worst-case target): {range_ns:,} ns per check")
print(f"list membership  (5K even nums, worst-case target): {list_ns:,} ns per check")
print(f"Speed ratio at 5K elements: ~{list_ns // max(range_ns, 1)}x")
print(f"At 50M elements, range stays ~{range_ns:,} ns. List would take ~{range_ns * 10_000:,} ns.")
print(f"range() is O(1) — list() is O(n). The gap widens linearly with collection size.")

# ── Never convert range() unless you need list-specific mutability ────────────
print("\n=== Valid index/membership operations without list conversion ===")
work_range = range(0, 50, 5)   # 0, 5, 10, 15, 20, 25, 30, 35, 40, 45

print(f"Index access   : work_range[3]  = {work_range[3]}")
print(f"Negative index : work_range[-1] = {work_range[-1]}")
print(f"Membership     : 25 in work_range = {25 in work_range}")
print(f"Membership     : 27 in work_range = {27 in work_range}")
print(f"Length         : len(work_range)  = {len(work_range)}")

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

Every range() confusion in production code traces back to one of two things: forgetting that stop is exclusive, or not knowing that step exists. Here is the complete syntax, once and for all: range(start, stop, step). Start is where counting begins — inclusive. Stop is where counting ends — but the stop value itself is never produced. Step is how much to add on each iteration.

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

The step argument is where range() earns its keep beyond toy loops. Batch processing every Nth record, building retry delays at a fixed interval, generating database page offsets, checking every even-numbered slot in a buffer — these all need step. For counting backwards, a negative step is all you need. There is no reversed() call required, no subtraction gymnastics. Just range(start, stop, -1) where start is numerically greater than stop. Stop is still exclusive in the negative direction — range(10, 0, -1) gives you 10 down to 1, because 0 is the stop and it is never included.

When you want to reverse a list and only need the values without indices, use reversed(my_list) — it is cleaner, requires no start/stop arithmetic, and works on any sequence regardless of whether it supports len(). Reserve range() with a negative step for situations where you genuinely need the decreasing index value — progress counters, countdown displays, decreasing batch offsets.

The one constraint worth memorising: step cannot be zero. range(0, 10, 0) raises ValueError: range() arg 3 must not be zero. A zero step would produce an infinite sequence of the start value — advancing by nothing means never terminating. Python raises an error here rather than silently returning an empty range, because the two cases have completely different meanings to the program. An empty range from an unsatisfiable start/stop condition is well-defined and may be intentional. A zero step almost always means a wrong variable was passed to the step argument — failing loudly prevents that from silently masking the bug.

# io.thecodeforge — Python tutorial
# Verified on CPython 3.12

# ── Scenario: A payment processor retry scheduler ─────────────────────────────
# Retry a failed charge at increasing intervals.
# Retry delays (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) → 1,2,3,4,5
    # 1-based attempt numbering for human-readable logging
    # stop is MAX_RETRIES + 1 because stop is exclusive — without the +1, attempt 5 is never reached
    delay = attempt_number * BASE_DELAY_SECONDS
    print(f"Attempt {attempt_number}: retry after {delay}s")

# ── Scenario: Counting backwards — leaderboard countdown ─────────────────────
print("\n=== Leaderboard Countdown (10 down to 1) ===")
for rank in range(10, 0, -1):  # start=10, stop=0 (exclusive), step=-1
    # stop=0 ensures rank 1 is included — stop is exclusive in both directions
    # range(10, 1, -1) would miss rank #1 — the same off-by-one in reverse
    print(f"  Rank #{rank}")

# ── Scenario: Reversing a list — when reversed() is cleaner than range ────────
print("\n=== reversed() for list reversal — no index arithmetic needed ===")
leaderboard = ["Alice", "Bob", "Charlie", "Diana", "Eve"]
for player in reversed(leaderboard):  # cleanest when you only need values, not indices
    print(f"  {player}")
# Use range(len(x)-1, -1, -1) only when you need the actual decreasing index value

# ── Scenario: Batch database writes — 100 records per batch ──────────────────
TOTAL_RECORDS = 450
BATCH_SIZE = 100

print("\n=== Batch Write Offsets ===")
for batch_start in range(0, TOTAL_RECORDS, BATCH_SIZE):  # 0, 100, 200, 300, 400
    # min() is critical here — without it, the final batch would request
    # indices 400 through 499, but only 400-449 exist
    batch_end = min(batch_start + BATCH_SIZE, TOTAL_RECORDS)
    record_count = batch_end - batch_start
    print(f"  Writing records [{batch_start}:{batch_end}] — {record_count} records")

# ── Scenario: Even-numbered port scanning for load balancer health checks ─────
PORT_START = 8080
PORT_END   = 8100
PORT_STEP  = 2

print("\n=== Even Port Range ===")
even_ports = list(range(PORT_START, PORT_END, PORT_STEP))  # small range — list is fine here
print(f"Ports to check: {even_ports}")

# ── Stop is always exclusive — demonstrating the rule across all forms ─────────
print("\n=== Stop Is Exclusive — Always ===")
print(f"range(5)         → {list(range(5))}")          # shorthand for range(0, 5, 1)
print(f"range(0, 5)      → {list(range(0, 5))}")       # 5 never appears
print(f"range(1, 6)      → {list(range(1, 6))}")       # when you need 1-5 inclusive
print(f"range(5, 0, -1)  → {list(range(5, 0, -1))}")   # 0 never appears
print(f"range(10, 10)    → {list(range(10, 10))}")     # empty when start == stop
print(f"range(10, 5)     → {list(range(10, 5))}")      # empty when start > stop with positive step

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 process one record too few or too many, the job reports success, and the corruption accumulates silently until someone notices a discrepancy or a customer surfaces the problem. The fintech incident that opened this guide was exactly this: range(1, record_count) where range(0, record_count) was correct. Index 0 never processed. Six weeks of silent nightly corruption.

There are exactly three failure modes worth memorising, because they cover the vast majority of off-by-one bugs in production Python code. First: range(1, n) when you mean range(0, n) — skips the first item, by far the most common pattern. Second: range(0, n-1) when you mean range(0, n) — skips the last item because stop is already exclusive, and subtracting 1 from it silently drops the final valid index n-1, so the loop visits indices 0 through n-2 and never touches the last element. Third: range(0, n+1) when you mean range(0, n) — processes one index past the end of the collection, causing an IndexError on the final iteration or, in dynamically-sized cases, quietly processing a sentinel or default value as real data.

All three produce wrong output with no exception, which is what makes them production-dangerous rather than merely annoying. They pass unit tests written against small test fixtures where the missing record is not checked. They pass integration tests that verify aggregate values rather than record counts. They run in production for days or weeks before the data discrepancy grows large enough to be noticed.

The rules that prevent all three: when iterating a list or array by index, always use range(len(collection)) — no manual arithmetic on start or stop. When you need a counted loop, use range(N). When you need both index and value, use enumerate(collection) — this eliminates range() from the equation entirely and makes off-by-one structurally impossible because enumerate() always generates the correct index for each item automatically.

# io.thecodeforge — Python tutorial
# Verified on CPython 3.12

# ── Real scenario: processing invoice line items for billing ──────────────────
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

# ── BUG 1: range(1, n) — skips index 0, first item silently missing ───────────
print("=== BUG 1: range(1, item_count) — skips first item ===")
bug1_total = 0.0
for i in range(1, item_count):  # produces 1, 2 — index 0 (WIDGET-A) never visited
    item = invoice_items[i]
    subtotal = item["qty"] * item["unit_price"]
    bug1_total += subtotal
    print(f"  Processed: {item['sku']} — ${subtotal:.2f}")
print(f"  Total billed: ${bug1_total:.2f}  ← WIDGET-A never billed (silent revenue loss)")

# ── BUG 2: range(0, n-1) — skips index n-1, last item silently missing ────────
# Stop is already exclusive. Subtracting 1 makes the loop visit 0 through n-2,
# skipping the final valid index n-1 (DOOHICKEY-C at index 2).
print("\n=== BUG 2: range(0, item_count - 1) — skips last item ===")
bug2_total = 0.0
for i in range(0, item_count - 1):  # produces 0, 1 — index 2 (DOOHICKEY-C) never visited
    item = invoice_items[i]
    subtotal = item["qty"] * item["unit_price"]
    bug2_total += subtotal
    print(f"  Processed: {item['sku']} — ${subtotal:.2f}")
print(f"  Total billed: ${bug2_total:.2f}  ← DOOHICKEY-C never billed (more silent revenue loss)")

# ── CORRECT: range(len(collection)) — covers every valid index ────────────────
print("\n=== CORRECT: range(len(invoice_items)) — all items processed ===")
correct_total = 0.0
for i in range(len(invoice_items)):  # produces 0, 1, 2 — every valid index visited
    item = invoice_items[i]
    subtotal = item["qty"] * item["unit_price"]
    correct_total += subtotal
    print(f"  Processed: {item['sku']} — ${subtotal:.2f}")
print(f"  Total billed: ${correct_total:.2f}  ← Correct")

# ── BETTER: enumerate() when you need index AND value ─────────────────────────
# enumerate() eliminates range() entirely — off-by-one is structurally impossible
# because enumerate() always produces the correct index for each item.
print("\n=== BETTER: enumerate() — index and value together, no range() needed ===")
enum_total = 0.0
for line_number, item in enumerate(invoice_items, start=1):  # 1-based line numbers
    subtotal = item["qty"] * item["unit_price"]
    enum_total += subtotal
    print(f"  Line {line_number}: {item['sku']} — ${subtotal:.2f}")
print(f"  Total billed: ${enum_total:.2f}  ← Correct, and off-by-one structurally impossible")

# ── Post-loop assertion: catch off-by-one before declaring success ─────────────
# This single line catches all three failure modes — range(1,n), range(0,n-1),
# range(0,n+1) — before partial results are written anywhere downstream.
print("\n=== Post-loop count assertion (add this to every batch processor) ===")
expected_count = len(invoice_items)
processed_count = 0
for item in invoice_items:
    processed_count += 1
assert processed_count == expected_count, (
    f"Expected {expected_count} records, processed {processed_count} — "
    f"possible off-by-one in range() call"
)
print(f"  Assertion passed: {processed_count}/{expected_count} records confirmed")

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 should not is a reliable tell that someone learned Python through C or Java and is carrying index-based loop habits into a language that does not need them. Here is the decision framework that should be 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 collection value. The clearest signal that range(n) is right: there is no collection being indexed — just a number of iterations.

Use range(len(collection)) only when you need to modify the list in-place by index — inserting at a specific position, swapping elements, zeroing out values, or when you need to access two lists simultaneously at the same index and zip() is not appropriate. This is the one use case where you genuinely need the raw index and range(len()) is the right tool.

Use a direct for item in collection loop when you only need the values — no index, no parallel list. This is the cleanest form and requires the least mental overhead when reading the code six months later.

Use enumerate(collection) when you need both the position and the value simultaneously — building numbered output, tracking which item failed in error logs, reporting progress through a large dataset. enumerate() gives you both at the same time without writing collection[i].

Use zip(list_a, list_b) when you need to walk two sequences in lockstep — pairing input records with expected outputs, merging two data streams by position, comparing before and after values side by side. One critical property of zip() that catches engineers out: it stops silently at the shorter sequence. If list_a has 10 elements and list_b has 9, zip() produces 9 pairs and the 10th element of list_a is silently ignored — no warning, no exception. When your two sequences might differ in length and you need to process all elements from both, use itertools.zip_longest(), which fills missing values with a fillvalue you specify.

These are not stylistic preferences — they are correctness decisions. range(len(x)) where a direct loop or enumerate() would do is flagged by Pylint (consider-using-enumerate) and Ruff (PERF101) for real reasons: it is harder to read, it introduces off-by-one surface area, and it signals to future maintainers that the index must be needed for something — which then requires them to trace through the loop body to discover it is just used to access the collection value.

# io.thecodeforge — Python tutorial
# Verified on CPython 3.12

import itertools

order_ids       = ["ORD-001", "ORD-002", "ORD-003", "ORD-004"]
order_statuses  = ["shipped", "pending", "cancelled", "shipped"]
priority_scores = [72, 45, 91, 38]

# ── range(n): pure counted loop — no collection involved ─────────────────────
print("=== range(n): run exactly N times ===")
for reminder_number in range(3):  # 0, 1, 2 — the count is all that matters here
    print(f"  Sending reminder #{reminder_number + 1}")
# Use _ instead of reminder_number when the value is genuinely unused:
# for _ in range(3): send_reminder()

# ── Direct iteration: reading values only — cleanest form ─────────────────────
print("\n=== Direct for-in: cleanest when index is irrelevant ===")
for order_id in order_ids:  # no range(), no index, no collection[i]
    print(f"  Dispatching notification for {order_id}")

# ── enumerate(): need position AND value — building an audit trail ─────────────
print("\n=== enumerate(): index + value together ===")
failed_positions = []
for position, order_id in enumerate(order_ids, start=1):
    # position tells us exactly where in the batch this failed — essential for error logs
    if order_id == "ORD-003":
        failed_positions.append(position)
        print(f"  Position {position}: {order_id} — FAILED")
    else:
        print(f"  Position {position}: {order_id} — OK")
print(f"  Failed at positions: {failed_positions}")

# ── zip(): two sequences in lockstep — and the silent truncation trap ──────────
print("\n=== zip(): walking two lists together ===")
for order_id, status in zip(order_ids, order_statuses):
    print(f"  {order_id} → {status}")

# ── zip() silent truncation — the bug zip() hides when lengths differ ─────────
print("\n=== zip() silent truncation — shorter list silently wins ===")
four_orders   = ["ORD-001", "ORD-002", "ORD-003", "ORD-004"]
three_statuses = ["shipped", "pending", "cancelled"]  # one fewer than orders

print("  With zip() — ORD-004 is silently dropped, no error raised:")
for order_id, status in zip(four_orders, three_statuses):
    print(f"    {order_id} → {status}")

print("  With zip_longest() — all orders processed, missing status filled:")
for order_id, status in itertools.zip_longest(four_orders, three_statuses, fillvalue="UNKNOWN"):
    print(f"    {order_id} → {status}")

# ── range(len(x)): legitimate use — in-place modification by index ─────────────
print("\n=== range(len(x)): in-place update — the one valid use case ===")
print(f"  Before: {priority_scores}")
for i in range(len(priority_scores)):   # need the index to WRITE BACK to the list
    if priority_scores[i] < 50:
        priority_scores[i] = 0          # zero out low-priority scores in place
print(f"  After:  {priority_scores}")
# This is the one case range(len(x)) is genuinely justified — you need the index to mutate

# ── O(1) membership testing — the interview question most candidates miss ──────
print("\n=== O(1) membership testing ===")
batch_offsets = range(0, 10_000_000, 100)   # valid page start positions
print(f"  Is 5000 a valid offset?    {5000 in batch_offsets}")
print(f"  Is 5001 a valid offset?    {5001 in batch_offsets}")
print(f"  Is 9999900 a valid offset? {9999900 in batch_offsets}")
# Each check is O(1) regardless of range size — no iteration, no scanning

Memory Profiling: When range() Makes Your SRE Grumpy

You’ve got a loop that iterates millions of times. Maybe you’re building a sliding window over log timestamps. On your laptop, it’s fine. In production with 16 cores and 128 GB RAM, it’s fine. Then your memory graph flatlines. The reason? range() doesn’t allocate a list of every integer. It yields one number at a time. That’s the whole point. But if you wrap it in list(), you just allocated every single value into RAM. For 0 to 10 million, that’s 80 MB for the integers alone, plus list overhead. Do that across multiple workers and OOM is instant. The fix: never materialize range unless you absolutely need random access. If your code has for i in list(range(big_number)), you’ve created a hidden memory bomb. Run a quick sys.getsizeof() check before you ship.

// io.thecodeforge — python tutorial

import sys

# range() itself is lazy — tiny memory footprint
default_range = range(10_000_000)
print(f"range object size: {sys.getsizeof(default_range)} bytes")

# list() materializes everything — this is where memory dies
materialized = list(range(10_000_000))
print(f"list size: {sys.getsizeof(materialized)} bytes")

# Real scenario: multi-worker batch processor
batch_ids = range(10_000_000)
pages = batch_ids[::1000]  # slicing range is still lazy in Python 3
print(f"lazy slice: {sys.getsizeof(pages)} bytes")

Negative Step Confusion: Why Your Reverse Loop Returns Nothing

You need to count down from ten to zero. You write range(10, 0, -1). That works. Then you need from ten to one. You write range(10, 1, -1). That stops at 2. One dev writes range(10, 0, -1) and gets 0. Another writes range(10, 1, -1) and misses 1. Next thing you know, a cron job skips the first record in a batch. The root cause is always the same: the stop value is exclusive, even when stepping backward. The logic is: start at start, keep going while the current value is greater than stop (if step negative). That means range(10, 0, -1) includes 1. But range(10, 0, -1) includes 0. To exclude 0, you need range(10, -1, -1). And to include 0, you need range(10, -1, -1). Wait — that’s the same. The trick: in the negative step, your stop is the value you want to land just short of. To hit 0, stop is -1. To hit 1, stop is 0. Internalize that and you stop shipping off-by-one bugs in reverse.

// io.thecodeforge — python tutorial

# Goal: print 10 down to 1 inclusive
# Wrong: misses 1
try_first = list(range(10, 1, -1))
print(f"Wrong (stops at 2): {try_first}")

# Wrong: includes 0
try_second = list(range(10, 0, -1))
print(f"Wrong (stops at 0): {try_second}")

# Correct: stop = 0 to exclude 0, but we want 1? 
# Actually we need stop = 0 to include 1 (goes down to 1, then next would be 0 which is <= stop)
correct = list(range(10, 0, -1))
print(f"Correct for 10 to 1: {correct}")

# To count from 10 to 0 inclusive
include_zero = list(range(10, -1, -1))
print(f"10 to 0: {include_zero}")

Floating Point Step: The Silent Data Corruption You Didn’t Sign Up For

You’re generating time series points. You write range(0, 10, 0.1) and Python throws a TypeError. Good. But the temptation is to switch to numpy.arange(). That works. Until it doesn’t. Floating point accumulation drifts. After 100 steps, 0.1 * 100 isn’t 10.0. It’s 9.99999999999998. Your loop stops one step early or includes an extra point, shifting your entire signal. Production servers log timestamps that don’t align. Your ML pipeline trains on misaligned data. The fix: use integer steps and divide after. range(0, 100, 1) -> x / 10. That’s exact. If you absolutely must use floats, use numpy.linspace() with the endpoint parameter explicitly set. But the safest pattern is always integer arithmetic. That kind of bug shows up as “random” off-by-one that changes with the phase of the moon. Don’t debug floating point accumulation after midnight. Just don’t use float steps.

// io.thecodeforge — python tutorial

# This crashes — Python range refuses floats
try:
    bad_range = range(0, 10, 0.1)
except TypeError as exc:
    print(f"Python says: {exc}")

# n00b workaround with numpy — contains drift
import numpy as np
floating_steps = np.arange(0, 10, 0.1)
print(f"Last value should be ~9.9, got: {floating_steps[-1]:.20f}")

# Correct way: integer arithmetic, no drift
exact_steps = [x / 10 for x in range(0, 100, 1)]
print(f"Last value exact: {exact_steps[-1]:.20f}")

# Production-grade pattern for timestamps
timestamps_exact = [0.0 + i * 0.1 for i in range(100)]
print(f"Timestamp 99: {timestamps_exact[99]:.20f}")

Parameters: What Each Argument Actually Controls

The range() function accepts up to three integer parameters, and each has a distinct role in sequence generation. The stop parameter is the only required argument; it defines the exclusive upper bound where iteration ceases. When only stop is given, start defaults to 0 and step to 1, producing range(stop) which yields 0, 1, ..., stop-1. Adding start sets the first value included; the sequence then increments by step until it reaches or exceeds stop. The step parameter controls direction and spacing: positive values count upward, negative values count downward. Crucial constraint: all parameters must be integers. Passing a float silently truncates toward zero or raises TypeError at runtime. The behavior of zero step is undefined and raises ValueError. Understanding parameters eliminates guesswork: you choose start for offset, stop for boundary, and step for stride. Misordering parameters is the root of off-by-N bugs in production loops.

// io.thecodeforge — python tutorial

# Understanding range parameters

# Single parameter: stop only
print(list(range(5)))      # [0, 1, 2, 3, 4]

# Two parameters: start, stop
print(list(range(2, 7)))   # [2, 3, 4, 5, 6]

# Three parameters: start, stop, step
print(list(range(1, 10, 2)))  # [1, 3, 5, 7, 9]

# Step direction matters
print(list(range(10, 0, -3))) # [10, 7, 4, 1]

# Zero step kills your process
# range(0, 5, 0)  # ValueError: range() arg 3 must not be zero

Create Subranges With Slices

Range objects support slicing, returning new range objects that represent subranges without materializing a list. Slice syntax range_obj[start:stop:step] applies the same parameter logic but to an existing sequence. This is memory-efficient: the slice produces another lazy range, not a list copy. The slice indices are relative to the source range's values, not its sequence positions. For example, range(10)[3:7] yields range(3, 7) because the slice extracts values 3 through 6 from the original 0..9 sequence. Slicing with step works analogously: range(0, 20, 2)[1:4] returns range(2, 8, 2) representing every other even number from index 1 to index 3. Critical warning: slicing a range never checks bounds until iteration. A slice like range(5)[10:20] creates an empty range; it evaluates lazily. This non-eager behavior catches developers off guard when slicing with computed indices that fall outside the original range's value space.

// io.thecodeforge — python tutorial

# Slicing ranges without lists

# Basic slice from range
r = range(10)
sub = r[3:8]
print(sub)          # range(3, 8)
print(list(sub))    # [3, 4, 5, 6, 7]

# Stepped slice
r2 = range(0, 20, 2)
sub2 = r2[1:4]
print(sub2)         # range(2, 8, 2)
print(list(sub2))   # [2, 4, 6]

# Out-of-bounds slice creates empty range
empty = range(5)[10:20]
print(list(empty))  # []

# Negative indices work
print(list(range(10)[-3:]))  # [7, 8, 9]