Most Python tutorials cover this in one sentence: sort() modifies the list in place and returns None; sorted() returns a new sorted list. That is accurate. But it leaves out the part that actually matters when you are writing a backend service.

In a short script, the difference is cosmetic. In a service where functions share data — through caches, through parameters, through objects passed across layers — sort() creates a category of bug that is genuinely hard to find. Not because it is complicated, but because it does not crash. The data just looks slightly wrong, and you spend time looking in the wrong places.

This article works through the mechanics: what Python does in memory when you call each function, what the GIL actually protects (and a common misconception about it), and a realistic incident pattern that shows how a single .sort() call can quietly corrupt shared state for weeks.

The Mutation Problem — How list.sort() Changes Data You Did Not Mean to Change

When you call my_list.sort(), Python rearranges the elements inside that list object. Every other variable that points to the same object immediately reflects the new order. There is no copy involved, no warning, and nothing in the output to indicate that anything changed.

In practice, the problem usually starts with a variable assignment that looks harmless. You rename a variable, pass a list into a function, or store something in a cache — and somewhere down the line, a sort on one name silently reorders the data seen through all the others.

A simple example of the aliasing problem

# Both names point at the same list object in memory.
raw = [5, 2, 9, 1]
audit_log = raw

def process(order_ids):
    order_ids.sort()       # sorts in place — no copy made
    return order_ids

result = process(raw)

print(audit_log)   # [1, 2, 5, 9] — insertion order is gone
print(raw)         # [1, 2, 5, 9] — same object, same result

The function sorted the caller’s list. audit_log still holds a reference to raw, so it also shows the sorted version. There was no crash, no exception — just missing data.

If that audit log was supposed to record arrival order for a reconciliation job or a replay system, the sequence of events is now wrong. The kind of wrong that takes a while to notice. If you want to understand how Python handles object references in general, this article on parameter passing in Python explains the mechanics clearly.

What CPython Does in Memory During sort() and sorted()

To understand why the mutation reaches all aliases, it helps to look at what a Python list actually is at the C level. CPython represents a list as a struct called PyListObject. It holds a pointer to an array of pointers — one pointer per element — along with a size count. The actual elements live elsewhere in memory.

You can read more about how CPython differs from other Python implementations in this comparison of CPython, Jython, and IronPython.

/* CPython — Objects/listobject.c (simplified) */
typedef struct {
    PyObject_VAR_HEAD
    PyObject **ob_item;   /* array of pointers to the list's elements */
    Py_ssize_t allocated; /* how many slots are allocated */
} PyListObject;

When list.sort() runs, Timsort rearranges the pointers inside ob_item. The element objects on the heap do not move. Only the order of pointers changes — inside the one PyListObject that all your variable names are pointing to. Every name that holds the address of that struct immediately sees the new order.

When sorted() runs, it creates a new PyListObject, copies the element pointers into it (incrementing reference counts along the way), and then sorts that new object. The original PyListObject is never touched. This is also why sorted() is safe to use with shared data — it never modifies the thing it was given. Python’s reference counting is covered in more detail in the Python garbage collection article if you want to understand how reference counts work in this context.

What the GIL Actually Guarantees During list.sort() — and Where the Common Explanation Goes Wrong

When you call list.sort() without a Python key function, the whole operation runs as a single C function call. The GIL is held throughout. No other Python thread can execute while the sort is running. As an implementation detail of CPython, the list appears empty to other threads during the sort — not partially sorted, just empty — and the final sorted result becomes visible all at once when the operation finishes.

The picture changes when you use a Python-level key function, such as key=lambda x: x.score. Every time Timsort calls that lambda, it executes Python bytecode, and the GIL can be released between those calls. During those windows, another thread can read the list while it is mid-sort. So partially sorted views are possible — but only when a Python key function is involved.

The actual risk: permanent shared mutation, not a torn read

Whether the GIL drops during the sort or not, the end result is the same: once sort() finishes, the list is reordered and every reference to it sees the new state. If that list lives in a cache, or was passed in as a parameter, every other part of the code that holds a reference now has different data than it started with. No exception is raised. Nothing is logged. The scope and lifetime of Python variables explains the reference model that makes this possible.

How This Bug Plays Out in Production — A Step-by-Step Incident

The following is a reconstruction of a pattern that comes up regularly in Python backend post-mortems. The details are illustrative, but the structure of the bug is real.

The fix is never the hard part with this kind of bug. What costs time is that the symptom — data in the wrong order — is easy to mistake for a logic error in a completely different part of the system.

Why sorted() Works Better in Data Pipelines

When data flows through a sequence of functions — filter, sort, transform, take the top N — each function ideally leaves its input unchanged. That way, you can test each step in isolation, pass the same input to multiple paths, and trust that the data at each stage is what you put in.

sorted() fits naturally into this model. .sort() does not. If you want to write non-mutating list transformations, list comprehensions are a good tool to combine with sorted() for the same reason.

# Each function returns a new list without touching its input.
def filter_active(users):
    return [u for u in users if u.is_active]

def rank_by_score(users):
    return sorted(users, key=lambda u: u.score, reverse=True)

def take_top(users, n=10):
    return users[:n]

result = take_top(rank_by_score(filter_active(all_users)))
# all_users is untouched. You can still use it, log it, or pass it elsewhere.

sorted() also enables safe memoization

Functions that do not mutate their inputs are much safer to memoize with functools.lru_cache. If a function calls .sort() on its input, the input has changed before any cache hit could be evaluated — you either get a cache miss (wasteful) or a cached result that was built on a different version of the data (wrong). sorted() avoids both problems.

Performance: Is sorted() Actually Slower?

Yes, slightly — and the reason is straightforward. sorted() allocates a new list object and copies element pointers before sorting begins. That allocation has a cost. For small-to-medium lists, the cost is in the range of microseconds. For very large lists in tight loops, it becomes measurable. If you are working on broader performance work, this Python optimization guide covers profiling and measurement techniques.

The overhead is roughly 10–15% regardless of list size, because the sorting itself — the O(n log n) comparison work — dominates in both cases. At one million elements, the gap is around 40 ms. If you are sorting a million-element list in a request handler, the sort is the least of your problems — that data should be sorted at the database level. You can read about how Python’s sorting algorithm works, including why Timsort performs well on partially sorted data.

When list.sort() Is Actually the Right Call

There are cases where .sort() is genuinely appropriate. The criteria are narrow, but they exist.

# Avoid: sorting, then creating a copy anyway
def get_sorted(items):
    items.sort()            # mutates caller's list
    return sorted(items)   # then pays the allocation cost too
    # You got the worst of both: mutation + allocation.

# Avoid: manual copy + sort when sorted() does the same thing
result = items[:]
result.sort()
# This is identical to sorted(items).
# Two lines instead of one, and less clear.

# Avoid: trusting sort()'s return value
result = items.sort()   # result is None
print(result[0])         # TypeError — comes up more often than you'd expect

sorted() Works on More Than Lists

One practical advantage that gets overlooked: sorted() accepts any iterable. In real service code, data does not always arrive as a list — it might come from a generator, a database cursor, a set, or a dict.keys() view. The Python lists guide covers the list type itself, but sorted() works across all of these without any changes to the calling code.

If you write code that uses sorted() throughout, your sort calls will keep working when the data source changes type. Switch a list to a generator or a query result, and sorted() handles it. .sort() calls become AttributeErrors at runtime.

A Note on Sort Stability — Both Functions Guarantee It

Both list.sort() and sorted() use Timsort, which is a stable sort. That means equal elements maintain their original relative order after sorting. If you sort user records by department name, users with the same department appear in the same order relative to each other as they did in the original list.

This is guaranteed by the Python language specification — not just CPython’s implementation — and it applies to both functions equally. It has been guaranteed since Python 2.2. Neither function is more or less stable than the other.

Quick Quiz — 10 Questions on sorted() and sort()

Summary

Frequently Asked Questions

Further Reading

If you want to go deeper on any of the topics covered here, these are worth reading.