Why does the Python slice items[1:4] return three elements, not four?

### Slices name gaps, not items Python's `s[start:stop:step]` is easiest to reason about if you picture the index positions as the *gaps between* elements rather than the elements themselves. For the string `"thumbnail"`, gap 0 sits before `t`, gap 1 between `t` and `h`, and gap 9 after the final `l`. A slice names two gaps and hands back everything between them, so `s[1:4]` is the material between gap 1 and gap 4 — the three characters `hum`. Stated the way an interviewer wants to hear it: the slice is **half-open**, `start` is included and `stop` is excluded. ### Three consequences, and they are the reason for the convention **Length arithmetic is plain subtraction.** With the default step of 1 and both bounds inside the sequence, `len(s[a:b]) == b - a`. No plus-one anywhere. A window of eight items starting at offset `i` is exactly `items[i:i+8]`, and the next window starts at `i+8`. **Slices tile.** `s[:k] + s[k:] == s` holds for every `k`. That identity is what makes chunking loops correct by construction: `s[0:8]`, `s[8:16]`, `s[16:24]` neither drop nor duplicate an element, because the gap that ends one chunk is the gap that begins the next. **The empty slice is expressible.** `s[a:a]` is empty. A closed-interval convention ("both ends included") cannot express an empty range without a special case, which is precisely the corner where off-by-one bugs breed. ### Negative indices Any negative index `i` is translated to `len(s) + i` before the slice is taken, so `-1` is the last element, `-2` the one before it, and `s[-3:]` reads as "the last three". This translation is a service the built-in sequences perform; it is not automatic in a class that implements `__getitem__` by hand, which must do the arithmetic itself. Negative indices compose with the half-open rule in the usual way: `s[:-1]` is "everything but the last", because the stop bound `len(s) - 1` is excluded. That reading is worth practising out loud, since it is the form most real code uses. ### Omitted bounds and the step An omitted `start` means the beginning, an omitted `stop` means the end, and `step` defaults to 1. The important subtlety is that the first two defaults are *direction-sensitive*: when `step` is negative, an omitted `start` means the **last** element and an omitted `stop` means "past the front". That is the whole explanation of `s[::-1]`: step backwards, starting at the end, running off the front — a reversed copy. A positive step skips: `s[::2]` is every other element from the start, `s[1::2]` every other element from position 1. Combining a step with bounds is legal (`s[1:8:3]`), and the count of items produced is `ceil((stop - start) / step)` rather than a simple subtraction. ### A slice produces a new object; an index produces an element `files[-1]` is the last element — a string, if the list holds strings. `files[-1:]` is a **list** containing one string. Confusing the two is one of the most common early bugs, and it shows up in error messages that look nonsensical (`AttributeError` on a list, a `TypeError` about concatenating a list to a string). The same asymmetry bites harder on `bytes`: slicing a `bytes` object gives `bytes`, but indexing one gives an `int`. Because a slice of a built-in sequence is a new object, `s[::-1]` never reverses in place. For a list, `list.reverse()` reverses the list itself and returns `None`, and the built-in `reversed()` gives a lazy iterator that copies nothing; `s[::-1]` is the option that costs a new sequence of the same length. For `str` and `tuple`, which are immutable, a copy is the only possibility. Building the slice is O(k) in the number of elements produced, so reversing a large list inside a hot loop is a real cost, not a free notation. ### The mental checklist When you read a slice, say four things to yourself: start is in, stop is out; negatives count from the end; missing bounds mean the ends, in the direction the step is going; and the result is a new sequence of the same type, never a view onto the original.