Complete Python tuple tutorial covering creation, immutability, packing, unpacking, named tuples, and when to choose tuples over lists. Tested examples on Python 3.14.6 with real output.

“Immutability changes everything.”

Raymond Hettinger, PyCon 2013

Last Updated: July 2026 | Tested on: Python 3.14.6 | Difficulty: Beginner | Reading Time: 15 minutes

A Python tuple is like a list that got laminated. Same indexing, same slicing, same looping. But once you create a tuple, it is sealed. You cannot append to it, remove from it, or swap an element. That sounds like a downside until you notice how much of your data was never supposed to change in the first place: a pair of map coordinates, a row pulled from a database, the three values a function hands back, the keys you look things up by.

Think of a printed boarding pass. The seat number on it is fixed. You cannot scribble a new seat onto the same pass; if your seat changes, the airline prints a fresh pass. A tuple works the same way. So the rule of thumb is simple: the moment you reach for a list and catch yourself thinking “wait, this should never be modified,” you actually want a tuple.

Creating Tuples

Tip: click the diagram to open it full screen, then use the zoom and pan controls for a closer look.

The diagram puts a Python tuple next to a list so you can see the one difference that matters: a tuple is immutable (you cannot change it after you make it), a list is mutable (you can). That fixed nature is not a missing feature. It is the whole point. Because a tuple cannot change, Python can hash it, which means you can use it as a dictionary key, drop it into a set, and pass it around without worrying that some other function quietly edits it behind your back. The shortcut to remember: if the data should not change, reach for a tuple.

📄 create_tuples.py: Multiple ways to create tuples

# Parentheses (most common)
point = (10, 20)
rgb = (255, 128, 0)
person = ("Rahul", 28, "Developer")

# Without parentheses, still a tuple (packing)
coordinates = 40.7128, -74.0060
print(f"Type: {type(coordinates)}")

# tuple() constructor
chars = tuple("Python")
nums = tuple(range(5))

# Empty tuple
empty = ()

print(f"Point: {point}")
print(f"Chars: {chars}")
print(f"Nums: {nums}")
print(f"Length: {len(person)}")

▶ Output

Type: <class 'tuple'>
Point: (10, 20)
Chars: ('P', 'y', 't', 'h', 'o', 'n')
Nums: (0, 1, 2, 3, 4)
Length: 3

What happened here: There are three ways to make a tuple, and the surprising one is the middle case. coordinates = 40.7128, -74.0060 has no parentheses at all, yet type() still reports a tuple. That is because the comma is what builds a tuple, not the brackets. The parentheses are just there for readability (and to remove ambiguity in places like function calls). The tuple() constructor takes anything you can loop over, so tuple("Python") walks the string letter by letter and tuple(range(5)) walks the numbers. Keep that comma rule in your back pocket, because the single-element catch near the end of this post hangs entirely on it.

Indexing and Slicing

Think of coaches on a train: each coach has a fixed position, and coach number 3 stays coach number 3 for the whole journey. Tuple positions work the same way, and the good news is that everything you already learned about list indexing carries over unchanged. Zero-based positions, negative indexing from the end, slicing. All of it works.

📄 indexing.py: Tuple indexing and slicing

colors = ("red", "green", "blue", "yellow", "purple")

print(f"First: {colors[0]}")
print(f"Last: {colors[-1]}")
print(f"Slice [1:4]: {colors[1:4]}")
print(f"Reversed: {colors[::-1]}")
print(f"'blue' in colors: {'blue' in colors}")

▶ Output

First: red
Last: purple
Slice [1:4]: ('green', 'blue', 'yellow')
Reversed: ('purple', 'yellow', 'blue', 'green', 'red')
'blue' in colors: True

One detail worth noticing: slicing a tuple hands you back a brand new tuple, not a list. That stays consistent across the board, so an operation on a tuple gives you a tuple. The original tuple is never touched, because it cannot be.

Immutability: The Core Rule

📄 immutability.py: You cannot change a tuple

point = (10, 20, 30)

# This will FAIL
try:
    point[0] = 99
except TypeError as e:
    print(f"Error: {e}")

# Can't append either
try:
    point.append(40)
except AttributeError as e:
    print(f"Error: {e}")

# But you CAN create a NEW tuple from an old one
new_point = point + (40,)
print(f"Original: {point}")
print(f"New: {new_point}")

▶ Output

Error: 'tuple' object does not support item assignment
Error: 'tuple' object has no attribute 'append'
Original: (10, 20, 30)
New: (10, 20, 30, 40)

What happened here: A tuple has no append, no remove, no insert, none of the methods that change a list in place. Try to assign to an index and Python raises a TypeError on the spot. So how do you get a “changed” tuple? You do not change the old one. You build a fresh one with concatenation (+) or slicing, exactly like the airline printing a new boarding pass. Notice in the output that point is still (10, 20, 30) after we built new_point. The original never moved.

Tuple Packing and Unpacking

Packing and unpacking work like a tiffin box. In the morning you pack several items into one box so they travel together; at lunch you open it and lay each item out separately. In the example below, the record of a backend developer named Niranjan travels as one packed Python tuple, and unpacking splits it back into name, age, and role in a single line.

📄 unpacking.py: Assign tuple elements to variables

# Packing: multiple values become a tuple
person = "Niranjan", 30, "Backend Dev"

# Unpacking: tuple elements become variables
name, age, role = person
print(f"{name}, age {age}, works as {role}")

# Star unpacking: catch the rest
scores = (95, 88, 72, 91, 84)
first, second, *rest = scores
print(f"Top 2: {first}, {second}")
print(f"Rest: {rest}")

# Ignore values with _
_, _, third = (10, 20, 30)
print(f"Third: {third}")

▶ Output

Niranjan, age 30, works as Backend Dev
Top 2: 95, 88
Rest: [72, 91, 84]
Third: 30

What happened here: Unpacking lets you hand each element its own name in a single line, no person[0], person[1], person[2] juggling. The *rest syntax is the greedy one: it grabs everything left over. One thing that trips people up, and you can see it in the output, is that rest comes back as a list [72, 91, 84], not a tuple. That is just how star-unpacking works. The underscore _ is a plain variable name that Python developers use as a polite way of saying “I have to catch this value, but I am going to ignore it.”

Swapping Variables

To swap water between two full glasses, you need a third empty glass. Most programming languages work the same way: swapping two variables needs a temporary third one. Python does not. In this example, two employee names, Viraj and Pravin, got stored in the wrong variables, and one line fixes it.

📄 swap.py: The Pythonic way to swap

a = "Viraj"
b = "Pravin"

# In other languages you'd need a temp variable
# temp = a; a = b; b = temp

# Python, tuple packing/unpacking under the hood
a, b = b, a
print(f"a = {a}, b = {b}")

▶ Output

a = Pravin, b = Viraj

What happened here: No temp variable, no third line. Python evaluates the whole right side first, packing b, a into a temporary tuple ("Pravin", "Viraj"), and only then unpacks it back into a and b. Both names get their new value at the same instant, so nothing gets clobbered halfway through. This one line is the tuple packing and unpacking from the last two sections doing real work.

Functions Returning Multiple Values

A food delivery arrives as one bag even when you ordered three dishes. The restaurant packs everything into a single bag, and you unpack it at your door. Python functions do the same: they always return one thing, but that one thing can be a tuple carrying several values.

📄 multiple_return.py: Tuples make multi-return natural

def analyze_scores(scores):
    return min(scores), max(scores), sum(scores) / len(scores)

marks = (72, 88, 95, 61, 84)
low, high, avg = analyze_scores(marks)
print(f"Low: {low}, High: {high}, Average: {avg:.1f}")

# The function actually returns a tuple
result = analyze_scores(marks)
print(f"Type: {type(result)}")
print(f"Value: {result}")

▶ Output

Low: 61, High: 95, Average: 80.0
Type: <class 'tuple'>
Value: (61, 95, 80.0)

What happened here: When a function ends with return a, b, c, there is no special “multiple return” feature at work. Python just packs those three values into one tuple and hands it back. The caller gets to decide how to receive it: unpack it into three separate names like low, high, avg, or catch the whole tuple in a single variable, as the second half of the example shows. Other languages make you build a little struct or wrapper object for this. Python developers reach for a tuple, and you will see this everywhere in real code.

Named Tuples

Plain tuples have one annoying weakness: they label things by position, not by name. Six months from now you will read person[2] in your own code and have no clue whether index 2 is the age, the score, or the job title. A named tuple fixes that. It works like a tuple in every way, but each slot also gets a real name you can read. In the example below, we track two quiz players named Anvi and Anvay.

📄 named_tuples.py: Self-documenting tuples

from collections import namedtuple

# Define a named tuple type
Player = namedtuple("Player", ["name", "age", "score"])

p1 = Player("Anvi", 26, 95)
p2 = Player("Anvay", 24, 88)

# Access by name, much clearer than p1[0]
print(f"{p1.name}: {p1.score} points")
print(f"{p2.name}: {p2.score} points")

# Still works with indexing
print(f"First field: {p1[0]}")

# Still immutable
try:
    p1.score = 100
except AttributeError as e:
    print(f"Error: {e}")

# Convert to dict
print(f"As dict: {p1._asdict()}")

▶ Output

Anvi: 95 points
Anvay: 88 points
First field: Anvi
Error: can't set attribute
As dict: {'name': 'Anvi', 'age': 26, 'score': 95}

What happened here: namedtuple builds you a small custom type on the fly. After that, p1.name and p1.score read like plain English, but you can still fall back to p1[0] when you need to, because a named tuple is still a real tuple underneath. It is also still immutable, so trying p1.score = 100 raises the same AttributeError you would get on any tuple. The handy _asdict() method gives you back a regular dictionary when you want to dump it to JSON (JavaScript Object Notation) or print it nicely. Think of it as the difference between a row of unlabeled boxes and the same row with a sticker on each box.

Tuples as Dictionary Keys

A dictionary key is like a house address: the postal system only works because the address stays fixed. If house number 12 could quietly rename itself to 47 overnight, no letter would ever arrive. That is exactly why Python demands unchangeable keys, and why tuples qualify while lists do not.

📄 tuple_keys.py: Tuples are hashable, lists are not

# Grid coordinates as dict keys
grid = {}
grid[(0, 0)] = "start"
grid[(2, 3)] = "treasure"
grid[(4, 4)] = "exit"

print(f"At (2,3): {grid[(2, 3)]}")

# Lists can't be dict keys
try:
    bad = {[1, 2]: "nope"}
except TypeError as e:
    print(f"Error: {e}")

▶ Output

At (2,3): treasure
Error: cannot use 'list' as a dict key (unhashable type: 'list')

What happened here: A dictionary key has to be hashable, which is a fancy way of saying its hash value must stay the same for its whole life. A tuple qualifies, because it can never change. A list does not, because it can, so Python refuses to let you use one as a key. On Python 3.14.6 the error even spells it out for you: cannot use 'list' as a dict key (unhashable type: 'list'). Using a coordinate pair like (2, 3) as a key, the way the grid does here, is a genuinely common reason tuples exist in the first place.

The Catch: Single-Element Tuple

📄 single_element.py: The trailing comma trap

# This is NOT a tuple, it's just parentheses around a string
not_a_tuple = ("hello")
print(f"Type: {type(not_a_tuple)}")  # str

# THIS is a single-element tuple, note the trailing comma
actual_tuple = ("hello",)
print(f"Type: {type(actual_tuple)}")  # tuple

# Also works without parentheses
also_tuple = "hello",
print(f"Type: {type(also_tuple)}")  # tuple

▶ Output

Type: <class 'str'>
Type: <class 'tuple'>
Type: <class 'tuple'>

This one catches every Python developer at least once. Here is the rule that saves you: the parentheses do not make a tuple, the comma does. So a one-item tuple needs that trailing comma. Write (42,), not (42). Without the comma, (42) is just the number 42 wearing a pair of brackets.

Common Mistakes

Mistake 1: Forgetting the comma in a single-element tuple

🚫 Not a tuple

t = (42)     # This is just the integer 42
type(t)      # <class 'int'>

✅ Proper single-element tuple

t = (42,)    # Trailing comma makes it a tuple
type(t)      # <class 'tuple'>

Mistake 2: Trying to sort a tuple in place

🚫 Tuples have no sort() method

nums = (5, 2, 8, 1)
# nums.sort()  # AttributeError: 'tuple' object has no attribute 'sort'

✅ Use sorted() to get a new sorted list

nums = (5, 2, 8, 1)
sorted_nums = sorted(nums)       # Returns a list
sorted_tuple = tuple(sorted(nums))  # Convert back to tuple

Best Practices

• DO use tuples for fixed collections: coordinates, RGB (Red, Green, Blue) colors, database rows
• DO use tuple unpacking for multi-value returns: x, y = get_position()
• DO use named tuples when tuple indices become confusing
• DO use tuples as dictionary keys when you need composite keys
• DON’T use a tuple when you need to add or remove elements. Use a list for that.
• DON’T forget the trailing comma on single-element tuples

Conclusion

So here is the whole post in short. A Python tuple is an immutable sequence. It shares indexing and slicing with lists, but you cannot change it once it exists. That fixed nature is what makes a tuple hashable (so it can be a dict key or a set member), a touch lighter than a list, and a clear signal to the next reader that this data is not meant to move. Tuple packing and unpacking is one of the cleanest tricks in the language, and you will lean on it constantly for swapping variables, returning several values at once, and pulling apart data into named pieces.

Next up: Dictionaries. Python’s key-value data structure for fast lookups. And if you want to browse every post in order, from absolute basics to AI/ML, head over to the Python + AI/ML tutorial series home.

Practice Exercises

1. Exercise 1: Create an RGB tuple and unpack into separate variables.
2. Exercise 2: Return min, max, average as a tuple from a function.
3. Exercise 3: Build a named tuple Point with distance, midpoint, and translation functions.

Frequently Asked Questions

Interview Questions on Python Tuples

The same ideas as they show up in real interviews, framed as scenarios you can practice out loud.

Q: You store grid coordinates as [x, y] lists and use them as dictionary keys. The program crashes with TypeError: unhashable type: 'list'. What is wrong and how do you fix it?

Dictionary keys must be hashable, and a list is not because it can change after creation. The fix is to convert each coordinate to a tuple: grid[(x, y)] = value or grid[tuple(pos)] = value. Tuples are immutable, so their hash stays stable for their whole life, which is exactly what a dict key needs.

Q: A teammate writes name, age = get_user() and it crashes with ValueError: too many values to unpack (expected 2). What do you check first?

Check how many values get_user() actually returns, because unpacking requires the variable count on the left to match the tuple length on the right. If the function now returns three values, either add a third variable or use star unpacking like name, age, *rest = get_user() to absorb the extras. Star unpacking is the safer pattern when the return shape might grow.

Q: How does a, b = b, a swap two variables without a temporary variable?

Python evaluates the entire right-hand side first, packing b, a into a temporary tuple, then unpacks that tuple into a and b. Both names receive their new values from the already-built tuple, so nothing is overwritten mid-swap. It is tuple packing and unpacking doing the work, not a special swap operator.

Q: When would you pick a namedtuple over a plain tuple or a dictionary?

Pick a namedtuple when positional access like row[2] hurts readability but you still want immutability and low memory use. Fields become readable attributes (player.score instead of player[2]) while indexing keeps working, because a namedtuple is still a tuple. A dictionary is better when the set of keys varies between records; a namedtuple is better when every record has the same fixed fields.

Q: Tuples only have two methods, count() and index(). Why so few compared to lists?

Every other list method (append, insert, remove, sort, and so on) mutates the object in place, and mutation is exactly what tuples forbid. Only the read-only methods survive: count() tells you how many times a value appears and index() tells you where it first appears. For anything else, you build a new tuple or convert to a list first.

Q: Is every tuple hashable?

No. A tuple is hashable only if all of its elements are hashable. A tuple containing a list, like ([1, 2], 3), raises TypeError the moment you try to hash it or use it as a dict key, because the inner list could still change. So “immutable” describes the tuple’s own structure, while “hashable” depends on everything inside it too.

Further reading: the official Python documentation is the authoritative source on this.

Related Posts

Previous: Python: Build a Number Guessing Game, Your First Real Program

Next: Python: Dictionaries, CRUD, Methods, and When to Use

Series Home: Python + AI/ML Tutorial Series