Python interview question: tuple vs list

I’d argue that number 5, semantics, really ought to be number 1. Once you understand what a tuple means, you’ll understand the reason for all the rest, and be able to choose the right one.

People are often distracted by the low level performance features of these data structures. So you see things like “use tuples because they are faster” (for iterating over), or because they use less memory etc. This can turn into a proliferation of tuples (for consistency and/or compatibility with other code that is expecting tuples). And then you start to have real performance problems:

You cannot actually extend a tuple at all - they are immutable. As you say “extending” a tuple is actually creating an entirely new tuple, with all the elements of the original one copied over (by reference). However, if you ever want to “extend” a tuple, you’ve got the wrong data-structure - semantically, a tuple is a structure with a fixed number of elements, each of which has a different meaning e.g. (name, email address) pair. It never makes any sense to extend a tuple, and that is why it is immutable.

So what does “extending” a tuple look like? Here is an example:

my_stuff = ()
for thing in things:
    my_stuff += (thing.stuff,)

I have seen code like this in the wild - do NOT write code like this! The third line is not adding a new element to the tuple - you are in fact creating an entirely new tuple, which has to copy the elements of the old one, and because of this you end up with quadratic time complexity in the length of things, which is very bad.

If you had used a list, as Guido intended, then you would be able to use list.append, which has excellent performance characteristics for this use case.

The lesson is to just use the data structure that semantically matches what you have. Everything else will follow, because the performance characteristics of these data structures, and all the other language features and stdlib behaviour, have been optimized for their intended usage (e.g. there is such a thing as a list comprehension, but no tuple comprehension).

Donald Knuth is extremely relevant:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

So we should worry about O(n²) performance (which is fixed by using the right data structure), and should not worry about tiny differences in memory/speed (which might be very different on other Python implementations, like PyPy for example).

I would argue that mutability has nothing to do with memory usage. Can you explain how one affects the other?

This is a really nice guide honestly. I feel like it covers all the aspects of these data types really well mate.