Why does slicing a `list` subclass return a plain `list` instead of the subclass?

## The observation Subclassing `list` looks like it works. You inherit every method, `isinstance(obj, list)` is true, and code that only appends and iterates is happy. Then someone takes a slice, and the subclass is gone: ```python class Stack(list): def push(self, item): self.append(item) s = Stack([1, 2, 3]) type(s[0:2]) # <class 'list'> type(s + [4]) # <class 'list'> type(s * 2) # <class 'list'> type(s.copy()) # <class 'list'> ``` A later `chunk.push(x)` raises `AttributeError`, usually far from the slice that caused it. ## Why the built-in behaves this way `list` is implemented in C. When `list.__getitem__` is handed a slice object it allocates a new list of the concrete built-in type and copies the item pointers into it. The same is true of `list.__add__` (`+`), `list.__mul__` (`*`) and `list.copy`. None of these ask the receiver what class it is. The reason is not laziness, it is that the built-in cannot construct your subclass safely. A subclass constructor may take any parameters at all — `Stack(name, capacity)` is perfectly legal — so there is no call the C code could make that is guaranteed to produce a valid instance. Rather than guess, the built-in returns the type it definitely knows how to build. Integers behave the same way: an `int` subclass plus one is an `int`. ## What does keep the type Anything that mutates the object you already have: - `s += [4]` goes through `list.__iadd__`, which extends in place and returns the same object. - `append`, `extend`, `insert`, `sort`, `reverse` and slice assignment all mutate in place. - `copy.copy` and `copy.deepcopy` rebuild the subclass, including its own attributes, because they go through the pickling protocol rather than through `list.copy`. Anything that produces a *new* sequence loses it: slicing, `+`, `*`, `sorted()`, `list(s)`, and comprehensions over `s`. ## Fix one: override the result-producing methods ```python class Stack(list): def __getitem__(self, index): result = super().__getitem__(index) return type(self)(result) if isinstance(index, slice) else result ``` That is one method of five, and it only works if `type(self)` accepts a single iterable. If your subclass takes extra constructor arguments you also have to decide what the slice should carry over — which is the moment most people notice they wanted composition, not inheritance. ## Fix two: `collections.UserList` `collections.UserList` is a pure-Python sequence that keeps the real list in an ordinary attribute named `data`. Because every method is written in Python, it can and does use `self.__class__`: ```python from collections import UserList class Stack(UserList): def push(self, item): self.append(item) s = Stack([1, 2, 3]) type(s[0:2]) # <class '__main__.Stack'> type(s + [4]) # <class '__main__.Stack'> ``` The price is speed — every operation is a Python-level call that forwards to the wrapped list — and one constructor constraint: `self.__class__(...)` is called with a single iterable, so a subclass whose `__init__` demands extra required arguments will blow up on the first slice. ## Which to reach for If the subclass only *adds* attributes and helper methods, and nothing downstream depends on the type after a slice, plain `list` is fine and fast. If the type identity matters — because callers do `isinstance` checks or rely on overridden behaviour of the result — use `collections.UserList`, or stop inheriting and hold a list as a private attribute, exposing exactly the operations your object supports. The last option is usually the one that survives review, because it also avoids inheriting fifteen mutating methods you never intended to offer. ## The interview point The answer an interviewer is listening for is *who constructs the result object*. Once you say "the C implementation builds a concrete `list` and never looks at `type(self)`", the fixes follow on their own, and the follow-up about `collections.UserList` is a short step rather than a memorised fact. ## The cost of the wrapper, and one interop trap `collections.UserList` is not free on either axis. Every operation is a Python-level call that forwards to the wrapped list, so a tight `append` loop runs roughly three times slower than on a built-in list. More surprising in practice: a `UserList` **is not a list**. `isinstance(obj, list)` is false, so any code that special-cases the built-in takes a different path or refuses the object outright — `json.dumps(UserList([1, 2]))` raises `TypeError: Object of type UserList is not JSON serializable`, and library code with a fast path for exact lists will fall back or fail. That is the trade in one line: subclassing `list` keeps interop and speed but loses the type on every derived result; subclassing `collections.UserList` keeps the type but loses `isinstance(obj, list)`. Pick according to which of the two your callers actually depend on, and if the answer is "neither, really", hold a list as a private attribute and expose the handful of operations your object is meant to support.