How does a custom class's __getitem__ tell an int index from a slice object?

### What the syntax actually produces The subscription `x[1:4]` is compiled to `type(x).__getitem__(x, slice(1, 4))`. The colons are syntax for constructing a `slice` object, nothing more, and that object is a perfectly ordinary value you can build yourself and pass around. Its three read-only attributes are `start`, `stop` and `step`, and crucially they hold **exactly what was written**: omitted bounds are `None`, not zero and not the length. `x[::2]` produces `slice(None, None, 2)`; `x[:-1]` produces `slice(None, -1, None)`. No normalisation has happened yet, because normalisation needs a length and the slice object does not know one. ### The branch A class that wants to support both forms therefore writes: ```python def __getitem__(self, key): if isinstance(key, slice): start, stop, step = key.indices(len(self._data)) return type(self)(self._data[i] for i in range(start, stop, step)) return self._data[key] ``` `slice.indices(length)` is the piece worth remembering by name. It applies precisely the algorithm the built-in sequences use — add the length to negative bounds, clamp into range, supply the direction-sensitive defaults for a negative step — and returns a `(start, stop, step)` triple guaranteed to be valid for `range()`. Writing that logic by hand is a reliable source of bugs, particularly the negative-step case where an omitted `stop` must mean "past the front" rather than 0. ### The integer branch is not free either A subtlety that catches people: for a custom class, **nothing translates a negative integer index for you**. If `__getitem__` stores its data in a list and forwards the key, the list does the translation and `x[-1]` works. If the class computes an offset itself, it must add `len(self)` when the index is negative and raise `IndexError` when the result is still out of range — raising `IndexError` matters, because that is the exception the iteration protocol relies on to stop a `for` loop over an object that has no `__iter__`. Integral keys also need not be `int`. Anything implementing `__index__` is an acceptable index in Python, so a strict `isinstance(key, int)` check rejects integer-like values the language would otherwise accept. Whatever falls through both branches should raise `TypeError`, which is what the built-in sequences do for a key they cannot interpret. ### Return-type convention Built-in sequences establish an expectation callers rely on: indexing returns an **element**, slicing returns a **new container of the same type**. A class whose slice branch returns a bare list when the class is not a list will surprise every caller who chains another operation onto the result. Whether the slice branch copies or returns a lazy view is a genuine design choice — a view avoids O(k) work but keeps the source alive and can expose later mutations — and it should be documented either way, because callers cannot see it from the call site. ### The mutating siblings `__setitem__` and `__delitem__` receive slice objects through exactly the same mechanism: `x[1:4] = value` calls `__setitem__(slice(1, 4), value)` and `del x[1:4]` calls `__delitem__(slice(1, 4))`. A mutable custom sequence must branch in all three methods, and if it supports a step it inherits the same question the built-in list answers with a `ValueError`: whether an extended-slice assignment may change the length. The usual answer is no. ### Multi-axis subscripts One more shape shows up in libraries with multi-dimensional data: `x[1:4, ::2]` builds a **tuple** whose members are two slice objects and passes that single tuple to `__getitem__`. That is the entire language-level mechanism behind multi-axis indexing in array libraries — there is no special syntax for it, just a tuple of slices. A plain sequence should reject a tuple key with `TypeError`, and the built-in list does exactly that. ### Where this comes up Inheriting from `collections.abc.Sequence` does not implement slicing for you: `__getitem__` remains abstract and the mixin methods it provides are built on top of whatever you write. So any class exposing a sequence-like façade — a lazily-loaded record set, a windowed buffer, a domain type wrapping a list — hits this the moment a caller writes a colon inside its brackets. Answering with `isinstance(key, slice)` plus `key.indices(len(self))`, the negative-index responsibility, and the same-type return convention covers everything an interviewer is looking for.