About Me

PBX I'm Paul Bissex, and e-scribe.com is my consulting business. I build web applications using open source software, especially Django. In the '90s I did graphic design for newspapers and magazines. Then I wrote technology commentary and reviews for Wired, Salon.com, Chicago Tribune, and lots of little places you've never heard of. Feel free to email me.

Book

I'm co-author of "Python Web Development with Django", an excellent guide to my favorite web framework. Published by Addison-Wesley, it is available from Amazon and your favorite technical bookstore as well.

Colophon

Built using Django, served by Apache and mod_wsgi. The database is SQLite. The operating system is FreeBSD, on a VPS hosted at Johncompanies.com. Comment-spam protection by Akismet. Vintage topo imagery from the Maptech archive. The markup engine is Markdown.

Pile o'Tags

Stuff I Use

Akismet, del.icio.us, Django, dpaste.com, Emacs, FreeBSD, Freenode, jQuery, LaunchBar, MacPorts, Markdown, Mercurial, OS X, Postfix, Python, SQLite, Subversion, TextMate, Trac, Ubuntu Linux, wmii

Spam Report

At least 70644 pieces of comment spam killed since January 2008, mostly via Akismet.

Understanding tuples vs. lists in Python

Python has two seemingly similar sequence types, tuples and lists.

The difference between the two that people notice right away, besides literal syntax (parentheses vs. square brackets), is that tuples are immutable and lists are mutable. Unfortunately, because this distinction is strictly enforced by the Python runtime, some other more interesting differences in application tend to get overshadowed.

One common summary of these more interesting, if subtle, differences is that tuples are heterogeneous and lists are homogeneous. In other words:

Tuples (generally) are sequences of different kinds of stuff, and you deal with the tuple as a coherent unit.
Lists (generally) are sequences of the same kind of stuff, and you deal with the items individually.

What are these "kinds of stuff" I'm talking about? Types? Sometimes. But types may not tell the whole story.

Consider the following two data structures:

>>> import time
>>> time.localtime()
(2008, 2, 5, 11, 55, 34, 1, 36, 0)

>>> range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

The first one, a tuple, is a sequence in which position has semantic value. The first position is always a year. This tuple functions as a lightweight record or struct.

The second one, a list, is a sequence where we may care about order, but where the individual values are functionally equivalent.

It's easy to imagine adding or removing items from the second one without breaking code that handles it or creating something undefined; for the first one, not so much.

A great example of the complementary use of both types is the Python DB API's fetchmany() method, which returns the result of a query as a list of tuples. The result set as a whole is a list, because rows are functionally equivalent (homogeneous); the individual rows are tuples, because rows are coherent, record-like groupings of (heterogeneous) column data.

A side note: Many functional languages, including Haskell and OCaml, have a similar distinction that is strictly enforced. Studying one of these languages may help clarify what I'm saying here; it certainly clicked for me when I started playing with Haskell.

There is considerable overlap in the ways tuples and lists can be used, but the built-in capabilities of the two structures highlight some of the above distinctions. For example, tuples have no 'index' method for identifying the position at which a particular value is found.

I've found that keeping the above distinctions in mind has helped me in my Python programming. Hopefully this attempt at clarification will help someone else!

Tuesday, February 5th, 2008
fp + haskell + programming + python + tips
10 comments

Some related posts: From PHP to Python • The Language I Will Kind of Learn in 2008: Smalltalk • OSCON 2007, Day 3 • Array comprehensions in Javascript • Real-World Haskell: A new book • Neat Python hack: infix operators • Learning Haskell inch by inch • The whitespace brigade • It's Haskell • The twenty-minute trouble ticket system

• Comment from Lorenzo Bolognini , later that day

The best thing I heard about the distinction of tuples vs. lists is that tuples have identity.

You would use tuples to represent a point (x,y): that alone already gives away the big semantic difference between tuples and lists and helps clarify that they are not *just* read-only lists.

In Django they're often used to represent, inside a list, an (id, value) pair that you can use in a Select widget.

Have a look at this [post][1] and the comment by Jayson Vantuyl.

[1]: http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/

• Comment from Chuck , later that day

The other nice side effect of tuples is that since the are immutable, they can be used as keys in dictionaries.

• Comment from Jim Storch , later that day

When people ask me about this I usually start my explanation with this abstraction:

Use a list when you need a bucket to put stuff in; "How can I get all these bricks to the roof?"

Use a tuple when you need a bucket of stuff; "Hope you enjoy this fruit basket."

• Comment from Vroo , 2 weeks later

Sorry, this is wrong. Tuples and lists may be either heterogeneous or homogeneous. (1,2), (1,'b'), [1,2] and [1,'b'] are all valid as are things like [1,(2,[3])]. While it may be the case that some developers use tuples for heterogeneous sets and others use lists for homogeneous sets, it's misleading to say that's the difference between the two.

The difference really is that lists are mutable. You can change the values in a list, append to it and delete values in it. You can't do that to a tuple.

• Comment from Paul , 2 weeks later

Vroo -- perhaps my use of the word "are" in my third paragraph made things sound too definitive. I'm not claiming to describe "the" difference between the two types; I address the obvious mutable/immutable distinction up front.

What I'm attempting to describe in this post is a common (and in my opinion valuable) convention that is easy to miss when one is first learning Python.

• Comment from rae , 18 months later

I think I'm starting to grasp the idea of tuples and lists. This might be a stupid question (I'm a newbie programmer), but I'm a bit confused as to in what conditions would you choose to use tuple over a list (since tuples are immutable, lists sound to be more useful maybe?)
Also, you mentioned that tuples can be more efficient, can you give a case for this?
Thanks!

• Comment from Shaggs , 2 years later

Thanks for the great page. As a C programmer learning python, I found the description given in the page to be very helpful - "I get it"!

• Comment from Titus Barik , 2 years later

Looks like one of your links is dead. The link to "Why are there separate tuple and list data types?" now returns a 404.

• Comment from Momus , 2 years later

Another case of an explanation which explains nothing.

I believe you that tuples and lists are used most often as you say.
But WHY is missing!!

To give a true understanding one must specify how Python deals with those types.
My guess (as a 2dn day Python "user"), is that tuples are are stored and/or accessed more efficiently. Which would be a good reason to use them if objects are immutable.

Years ago, when learning C++ I found only one book to be truly useful, by Stroustrup's C++ Reference Manual. Because n the book Stroustrup would give suggestion as to how each feature would be implemented by a compiler. This is the only way to give user a feel of what to use when, when efficiency is a must. And if it's not important then any garbage code will do, as we see all too often...

• Comment from Paul , 2 years later

Titus: Thanks for noticing; the passage in question has disappeared from the Python docs, so I've removed the link.

Momus: Welcome to the world of Python! As for the "why" -- in my opinion it's a useful semantic distinction that produces code that's easier to read and maintain. As a bonus, as I suggest above, it also paves the way to experience with interesting functional programming languages like Haskell.