How do list.copy(), lst[:] and copy.deepcopy() differ when copying a Python list?

### First: assignment is not a copy `b = a` creates no object. It binds another name to the list `a` already refers to, so `b is a` is `True` and `b.append(1)` is visible through `a`. Every discussion of copying starts here, because the bug being fixed is usually “I thought I had my own list”. ### The shallow copies, and why there are four spellings Four expressions produce an equivalent result: ```python import copy a = [[1, 2], [3, 4]] c1 = a.copy() c2 = a[:] c3 = list(a) c4 = copy.copy(a) ``` Each allocates a new list of the same length and stores the same element references into it, incrementing each element's reference count. Afterwards `c1 is not a` but `c1[0] is a[0]`. Structural mutation — `append`, `remove`, sorting the copy — affects only the copy. Mutating an element *through* the copy, such as `c1[0].append(9)`, is visible in the original, because both lists point at that one inner object. The spellings differ only in style and generality. `list(a)` accepts any iterable, which makes it the right choice when the source may be a generator or a tuple. `a.copy()` reads most clearly when the source is definitely a list and appeared in 3.3. `a[:]` is the oldest idiom and the one newcomers misread as “copying the data”. `copy.copy(a)` is the generic, type-agnostic form, useful when the object type is unknown. Cost is O(n) pointer copies — cheap and predictable, whatever the elements are, because nothing inside them is inspected. ### Deep copy `copy.deepcopy(a)` recursively copies the elements, and their elements, all the way down. Two mechanisms make that safe: **A memo table.** `deepcopy` keeps a dictionary keyed by the identity of everything it has already copied. That means a structure containing a reference to itself terminates instead of recursing forever, and — just as importantly — an object referenced from two places in the source is copied *once* and referenced from both places in the clone, preserving the sharing topology rather than silently duplicating. **Per-type hooks.** A class can control how it is deep-copied; where it does not, `deepcopy` falls back to a reconstruction protocol shared with pickling. That is also where deep copy fails: an object that cannot be pickled — a lock, a socket, an open file, a live database handle — raises `TypeError` from `deepcopy`. Discovering that in a request path is a common production surprise. Cost is proportional to the whole reachable object graph, not to `len(a)`, plus dictionary bookkeeping per object. On a large nested structure it is orders of magnitude slower than the shallow forms. ### Choosing Ask one question: *will anything mutate an object reached through the copy?* - If the elements are immutable — ints, strings, tuples of immutables — a shallow copy is already a complete copy, and deep copy buys nothing but cost. - If only the top level will be restructured — appending, filtering, reordering — shallow is correct. - If nested mutables will be modified independently, you need depth. Often you need exactly *one* level of it, and a comprehension gives that far more cheaply and far more legibly than a full deep copy: `[dict(rec) for rec in records]` or `[inner.copy() for inner in rows]`. - Reach for `copy.deepcopy` when the structure is arbitrarily nested, heterogeneous, or not under your control — and treat it as a cost you have accepted deliberately. A fourth option is worth naming: build the new structure rather than copying one. Where the data came from a serialized form, re-parsing it is sometimes both faster and clearer than deep-copying an in-memory graph, and it sidesteps the unpicklable-object problem entirely. ### What interviewers look for That you distinguish three things — binding a name, copying the container, copying the contents — and that you do not reach for `deepcopy` by reflex. “Use deepcopy to be safe” is the answer that marks a candidate down, because it converts a correctness question into an unbounded cost.