The last collection type in our survey is the Python tuple. Tuples construct simple groups of objects. They work exactly like lists, except that tuples can’t be changed in place (they’re immutable) and are usually written as a series of items in parentheses, not square brackets. Although they don’t support as many methods, tuples share most of their properties with lists. Here’s a quick look at the basics. Tuples are:
Like strings and lists, tuples are positionally ordered collections of objects (i.e., they maintain a left-to-right order among their contents); like lists, they can embed any kind of object.
Like strings and lists, items in a tuple are accessed by offset (not by key); they support all the offset-based access operations, such as indexing and slicing.
Like strings and lists, tuples are sequences; they support many of the same operations. However, like strings, tuples are immutable; they don’t support any of the in-place change operations applied to lists.
Because tuples are immutable, you cannot change the size of a tuple without making a copy. On the other hand, tuples can hold any type of object, including other compound objects (e.g., lists, dictionaries, other tuples), and so support arbitrary nesting.
Like lists, tuples are best thought of as object reference arrays; tuples store access points to other objects (references), and indexing a tuple is relatively quick.
Table 9-1 highlights common tuple operations. A tuple is written as a series of objects (technically, expressions that generate objects), separated by commas and normally enclosed in parentheses. An empty tuple is just a parentheses pair with nothing inside.
Table 9-1. Common tuple literals and operations
|
Operation |
Interpretation |
|---|---|
|
|
|
|
|
A one-item tuple (not an expression) |
|
|
A four-item tuple |
|
|
Another four-item tuple (same as prior line) |
|
|
|
|
|
Tuple of items in an iterable |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As usual, let’s start an interactive session to explore tuples at work. Notice in Table 9-1 that tuples do not have all the methods that lists have (e.g., an append call won’t work here). They do, however, support the usual sequence operations that we saw for both strings and lists:
>>>(1, 2) + (3, 4)# Concatenation (1, 2, 3, 4) >>>(1, 2) * 4# Repetition (1, 2, 1, 2, 1, 2, 1, 2) >>>T = (1, 2, 3, 4)# Indexing, slicing >>>T[0], T[1:3](1, (2, 3))
The second and fourth entries in Table 9-1 merit a bit more explanation. Because parentheses can also enclose expressions (see Chapter 5), you need to do something special to tell Python when a single object in parentheses is a tuple object and not a simple expression. If you really want a single-item tuple, simply add a trailing comma after the single item, before the closing parenthesis:
>>>x = (40)# An integer! >>>x40 >>>y = (40,)# A tuple containing an integer >>>y(40,)
As a special case, Python also allows you to omit the opening and closing parentheses for a tuple in contexts where it isn’t syntactically ambiguous to do so. For instance, the fourth line of Table 9-1 simply lists four items separated by commas. In the context of an assignment statement, Python recognizes this as a tuple, even though it doesn’t have parentheses.
Now, some people will tell you to always use parentheses in your tuples, and some will tell you to never use parentheses in tuples (and still others have lives, and won’t tell you what to do with your tuples!). The most common places where the parentheses are required for tuple literals are those where:
Parentheses matter—within a function call, or nested in a larger expression.
Commas matter—embedded in the literal of a larger data structure like a list or dictionary, or listed in a Python 2.X print statement.
In most other contexts, the enclosing parentheses are optional. For beginners, the best advice is that it’s probably easier to use the parentheses than it is to remember when they are optional or required. Many programmers (myself included) also find that parentheses tend to aid script readability by making the tuples more explicit and obvious, but your mileage may vary.
Apart from literal syntax differences, tuple operations (the middle rows in Table 9-1) are identical to string and list operations. The only differences worth noting are that the +, *, and slicing operations return new tuples when applied to tuples, and that tuples don’t provide the same methods you saw for strings, lists, and dictionaries. If you want to sort a tuple, for example, you’ll usually have to either first convert it to a list to gain access to a sorting method call and make it a mutable object, or use the newer sorted built-in that accepts any sequence object (and other iterables—a term introduced in Chapter 4 that we’ll be more formal about in the next part of this book):
>>>T = ('cc', 'aa', 'dd', 'bb')>>>tmp = list(T)# Make a list from a tuple's items >>>tmp.sort()# Sort the list >>>tmp['aa', 'bb', 'cc', 'dd'] >>>T = tuple(tmp)# Make a tuple from the list's items >>>T('aa', 'bb', 'cc', 'dd') >>>sorted(T)# Or use the sorted built-in, and save two steps ['aa', 'bb', 'cc', 'dd']
Here, the list and tuple built-in functions are used to convert the object to a list and then back to a tuple; really, both calls make new objects, but the net effect is like a conversion.
List comprehensions can also be used to convert tuples. The following, for example, makes a list from a tuple, adding 20 to each item along the way:
>>>T = (1, 2, 3, 4, 5)>>>L = [x + 20 for x in T]>>>L[21, 22, 23, 24, 25]
List comprehensions are really sequence operations—they always build new lists, but they may be used to iterate over any sequence objects, including tuples, strings, and other lists. As we’ll see later in the book, they even work on some things that are not physically stored sequences—any iterable objects will do, including files, which are automatically read line by line. Given this, they may be better called iteration tools.
Although tuples don’t have the same methods as lists and strings, they do have two of their own as of Python 2.6 and 3.0—index and count work as they do for lists, but they are defined for tuple objects:
>>>T = (1, 2, 3, 2, 4, 2)# Tuple methods in 2.6, 3.0, and later >>>T.index(2)# Offset of first appearance of 2 1 >>>T.index(2, 2)# Offset of appearance after offset 2 3 >>>T.count(2)# How many 2s are there? 3
Prior to 2.6 and 3.0, tuples have no methods at all—this was an old Python convention for immutable types, which was violated years ago on grounds of practicality with strings, and more recently with both numbers and tuples.
Also, note that the rule about tuple immutability applies only to the top level of the tuple itself, not to its contents. A list inside a tuple, for instance, can be changed as usual:
>>>T = (1, [2, 3], 4)>>>T[1] = 'spam'# This fails: can't change tuple itself TypeError: object doesn't support item assignment >>>T[1][0] = 'spam'# This works: can change mutables inside >>>T(1, ['spam', 3], 4)
For most programs, this one-level-deep immutability is sufficient for common tuple roles. Which, coincidentally, brings us to the next section.
This seems to be the first question that always comes up when teaching beginners about tuples: why do we need tuples if we have lists? Some of the reasoning may be historic; Python’s creator is a mathematician by training, and he has been quoted as seeing a tuple as a simple association of objects and a list as a data structure that changes over time. In fact, this use of the word “tuple” derives from mathematics, as does its frequent use for a row in a relational database table.
The best answer, however, seems to be that the immutability of tuples provides some integrity—you can be sure a tuple won’t be changed through another reference elsewhere in a program, but there’s no such guarantee for lists. Tuples and other immutables, therefore, serve a similar role to “constant” declarations in other languages, though the notion of constantness is associated with objects in Python, not variables.
Tuples can also be used in places that lists cannot—for example, as dictionary keys (see the sparse matrix example in Chapter 8). Some built-in operations may also require or imply tuples instead of lists (e.g., the substitution values in a string format expression), though such operations have often been generalized in recent years to be more flexible. As a rule of thumb, lists are the tool of choice for ordered collections that might need to change; tuples can handle the other cases of fixed associations.
In fact, the choice of data types is even richer than the prior section may have implied—today’s Python programmers can choose from an assortment of both built-in core types, and extension types built on top of them. For example, in the prior chapter’s sidebar Why You Will Care: Dictionaries Versus Lists, we saw how to represent record-like information with both a list and a dictionary, and noted that dictionaries offer the advantage of more mnemonic keys that label data. As long as we don’t require mutability, tuples can serve similar roles, with positions for record fields like lists:
>>>bob = ('Bob', 40.5, ['dev', 'mgr'])# Tuple record >>>bob('Bob', 40.5, ['dev', 'mgr']) >>>bob[0], bob[2]# Access by position ('Bob', ['dev', 'mgr'])
As for lists, though, field numbers in tuples generally carry less information than the names of keys in a dictionary. Here’s the same record recoded as a dictionary with named fields:
>>>bob = dict(name='Bob', age=40.5, jobs=['dev', 'mgr'])# Dictionary record >>>bob{'jobs': ['dev', 'mgr'], 'name': 'Bob', 'age': 40.5} >>>bob['name'], bob['jobs']# Access by key ('Bob', ['dev', 'mgr'])
In fact, we can convert parts of the dictionary to a tuple if needed:
>>>tuple(bob.values())# Values to tuple (['dev', 'mgr'], 'Bob', 40.5) >>>list(bob.items())# Items to tuple list [('jobs', ['dev', 'mgr']), ('name', 'Bob'), ('age', 40.5)]
But with a bit of extra work, we can implement objects that offer both positional and named access to record fields. For example, the namedtuple utility, available in the standard library’s collections module mentioned in Chapter 8, implements an extension type that adds logic to tuples that allows components to be accessed by both position and attribute name, and can be converted to dictionary-like form for access by key if desired. Attribute names come from classes and are not exactly dictionary keys, but they are similarly mnemonic:
>>>from collections import namedtuple# Import extension type >>>Rec = namedtuple('Rec', ['name', 'age', 'jobs'])# Make a generated class >>>bob = Rec('Bob', age=40.5, jobs=['dev', 'mgr'])# A named-tuple record >>>bobRec(name='Bob', age=40.5, jobs=['dev', 'mgr']) >>>bob[0], bob[2]# Access by position ('Bob', ['dev', 'mgr']) >>>bob.name, bob.jobs# Access by attribute ('Bob', ['dev', 'mgr'])
Converting to a dictionary supports key-based behavior when needed:
>>>O = bob._asdict()# Dictionary-like form >>>O['name'], O['jobs']# Access by key too ('Bob', ['dev', 'mgr']) >>>OOrderedDict([('name', 'Bob'), ('age', 40.5), ('jobs', ['dev', 'mgr'])])
As you can see, named tuples are a tuple/class/dictionary hybrid. They also represent a classic tradeoff. In exchange for their extra utility, they require extra code (the two startup lines in the preceding examples that import the type and make the class), and incur some performance costs to work this magic. (In short, named tuples build new classes that extend the tuple type, inserting a property accessor method for each named field that maps the name to its position—a technique that relies on advanced topics we’ll explore in Part VIII, and uses formatted code strings instead of class annotation tools like decorators and metaclasses.) Still, they are a good example of the kind of custom data types that we can build on top of built-in types like tuples when extra utility is desired.
Named tuples are available in Python 3.X, 2.7, 2.6 (where _asdict returns a true dictionary), and perhaps earlier, though they rely on features relatively modern by Python standards. They are also extensions, not core types—they live in the standard library and fall into the same category as Chapter 5’s Fraction and Decimal—so we’ll delegate to the Python library manual for more details.
As a quick preview, though, both tuples and named tuples support unpacking tuple assignment, which we’ll study formally in Chapter 13, as well as the iteration contexts we’ll explore in Chapter 14 and Chapter 20 (notice the positional initial values here: named tuples accept these by name, position, or both):
>>>bob = Rec('Bob', 40.5, ['dev', 'mgr'])# For both tuples and named tuples >>>name, age, jobs = bob# Tuple assignment (Chapter 11) >>>name, jobs('Bob', ['dev', 'mgr']) >>>for x in bob: print(x)# Iteration context (Chapters 14, 20)...prints Bob, 40.5, ['dev', 'mgr']...
Tuple-unpacking assignment doesn’t quite apply to dictionaries, short of fetching and converting keys and values and assuming or imposing an positional ordering on them (dictionaries are not sequences), and iteration steps through keys, not values (notice the dictionary literal form here: an alternative to dict):
>>>bob = {'name': 'Bob', 'age': 40.5, 'jobs': ['dev', 'mgr']}>>>job, name, age = bob.values()>>>name, job# Dict equivalent (but order may vary) ('Bob', ['dev', 'mgr']) >>>for x in bob: print(bob[x])# Step though keys, index values...prints values...>>>for x in bob.values(): print(x)# Step through values view...prints values...
Watch for a final rehash of this record representation thread when we see how user-defined classes compare in Chapter 27; as we’ll find, classes label fields with names too, but can also provide program logic to process the record’s data in the same package.