The Third Bit

Tuples are not constant lists — this is a common misconception. Lists are intended to be homogeneous sequences, while tuples are hetereogeneous data structures.

If you compare Java programs to Python, you’ll often find lots of trivial classes whose sole purpose is to be a simple pair or triple of differently-typed data values: i.e. tuples.

PyPy and Psyco make intelligent use of this distinction in intended uses, by using simple C struct types for tuples, vs. using dynamically-allocated arrays for lists.

It may be a “misconception”, but (a) that’s how almost all of the Python programmers I know think about them, (b) having both is a continual source of confusion for newcomers, and (c) since there’s nothing to prevent lists being used for heterogeneous data, the distinction is purely stylistic (and often ignored). I think we should acknowledge the facts on the ground…

a) that lots of people think something doesn’t make it any less wrong

b) documentation patches would help

c) Psyco, PyPy and ShedSkin all treat tuples and lists differently when producing low-level code, because this enhances their ability to do typechecking. So the difference is already not merely stylistic, any more than the distinction between functions and methods is stylistic. Indeed, CPython uses different memory allocation techniques for the two, and it can make a significant difference to performance in CPython, depending on the platform’s malloc speed.

So the “facts on the ground” are that they are not interchangeable, either conceptually or in implementation terms. Even educationally speaking, it would be a bad idea to start talking about “immutable lists”, if you expect to have reasonable crossover with other CS courses: note that relational database theory includes the notion of tuples, and numerous functional programming languages use the term as well, meaning almost exactly the same thing as in Python. Deciding to call it something else to make it easy on beginners is impoverishing, not helping. (Guido refers to this as the “ABC mistake”.)

If you have to explain a tuple to someone without a CS background, it’s better to compare it to an “assortment” or “combination platter”, not an immutable list. Think of a Chinese restaurant menu where you can have “one item from column A, and one from column B”. Or the rows of a table or spreadsheet – if rows are in a list, then each row is a tuple. A tuple is only a sequence because it sometimes makes sense to treat the items in the row in sequence.

Greg, thanks for your comments on my blog.

I’ve posted some ideas there in a further comment but thought they’d be worth suggesting here too…

I agree that we’ve conflated mutability with homogeneity/heterogeneity.

The first step to fixing that would be to have an immutable list type. (frozenlist?)

The second would be to support item assignment (but still not append) on tuples (and maybe introduce a frozentuple that doesn’t support this)

The third would be to change the behaviour of things like tuple + tuple. The fact that works the way it does in Python today is the sort of thing that causes the confusion.

If I was going to replace tuples with something, it would be structs – by far the most common use of typles I’ve seen (and done myself) is as structs-without-field-names. Often this is done for performance reasons, when the only alternative is a dictionary.

As I said in email to James T., Python’s current implementation of lists and tuples conflates two logically-separate ideas: mutability vs. immutability, and homogeneity vs. heterogeneity. The language only enforces the first; since the second is a matter of choice, I believe the majority of Python programmers are either ignorant of it, or ignore it.

We already have (in sets vs. frozen sets) an example which peels the two concepts apart. If homogeneity of lists isn’t going to be enforced by the language in P3K, I vote for bowing to common practice.

As someone for whom Python is the only language which I know in at any level of depth – which is *not* the depth of present company – it has been and remains hard to understand homogenous/list meme.

Whatever is being said here seems to being drawn from domains outside of Python. None of the thinking that has been native and necessary to learning Python and writing practical code and solving problems from *within* Python would have me make the connection between homogenuity and the use of lists.

That there are technical reasons related to performance, extension writing, etc where the meme becomes more meaningful is perhaps true.

But on the pure Python coding level the connection seems more than just mysterious to me – almost a mystification.

I’ve been writing Python code for 5 years. And I hate to think, or perhaps admit, that something claimed to be so fundamental about the language escapes me so thoroughly.

Art

(2006, “May”, 1) and (“May”, 1, 15) are very different structures.

["Alice", "Bob", "Charlie"] and ["Bob", "Charlie", "Daniel"] are the same kind of structure, and just happens to have different values.

The real question is whether this distinction is still helpful.

date.year, date.month, date.day is better than date[0], date[1], date[2].

Is there any reason (other than efficiency or history) to use tuples instead of objects with named attributes? If not, then they probably should be viewed as immutable lists.

Indeed, structs would be very welcome. I have had enough of tuple madness already.

While x[1] is expected to have a special semantic meaning compared to x[0] and x[n>1], the value of 1 does not denote anything at all. It does not mean the same for x as for z, q, and m. It doesn’t tell you what it is about as would a meaningful name.

Darn, though, tuples are useful for multiple return values. I still return tuples rather a lot, and have kept many lists of tuples and dictionaries of tuples-to-tuples. I love the darned things, especially with the pack/unpack syntax ( x,y = tupleN).

Confession time: I will use tuples until they start to confuse me enough that I make a class with named data attributes, or until I need to modify them and change over to a list (yes, a heterogenous one) against best practice as described here. I would use the daylight out of lightweight structs.

In fact, I think I’ll go invent some.

Writing a class just to make a named-attribute tuple is both expensive and not a good practice at all.

A great advantage of tuples is that they are really simple to use, you can construct them on the same block of code that you’re working on, and, compared to lists, they are hashable, which is great, as the two most important data structures in Python (tuples and dictionaries) can work together like a charm.