Since tuples are immutable, I think of them as fixed data objects with some simple sequential structure, as opposed to lists which are much more dynamically accessible/updateable data containers. Back in my relational database design days, I sometimes had to create a primary key for a table by combining values stored in two or more columns - neither column value alone was unique, but the combination of them was, and so made a good retrieval index. In Python, such data pairs would be ideally represented with tuples, in support of in-memory data cacheing or tree indexing - for a given record, the values don't change, so the immutability of their tupleness doesn't get in the way.
In similar vein, I've used tuples internally in my Python code as cache keys for function memoizing. They are WORM structures - write once, read many - built to represent the cache value, but never updated. With this idea of tuples as a data structure, I could reasonably interpret this: (1,"abc",3) + [1] to result in (1,"abc",3,[1]) just as well as (1,"abc",3,1). But instead of just picking one, Python complains about this, and so forces me to explicitly use (1,"abc",3) + tuple([1]) or (1,"abc",3) + ([1],) I don't think tuples are just an academic curiosity, as your post seems to suggest. -- Paul -- http://mail.python.org/mailman/listinfo/python-list