Sequences — Lists, Tuples & Strings as One Abstraction

Lists, tuples, and strings look like three separate topics. They aren't. They're three implementations of one abstraction — the sequence: an ordered collection you can index, slice, and iterate. Learn the shared protocol once and three "topics" collapse into one, with the differences reducing to a single axis: mutable or not.

This is the deep pass of Lists, the Basics and Strings, the Basics — it assumes you've met both and pushes into slicing, tuples, unpacking, and complexity. Every output below was produced by running the code.

Table of Contents

1. The sequence abstraction
2. Indexing, including negatives
3. Slicing — the power tool
4. Operations every sequence shares
5. Lists — the mutable workhorse
6. Tuples — the immutable record
7. Strings — immutable text sequences
8. Unpacking
9. Complexity: what's fast, what's slow
10. Mental-model summary

1. The sequence abstraction

A sequence is any ordered collection supporting a common set of operations: get an item by integer position (seq[i]), take a sub-range (seq[a:b]), measure length (len), test membership (x in seq), concatenate (+), repeat (*), and iterate (for x in seq).

Output:

a c 3 True
a c 3 True
a c 3 True

Analysis. A list, a tuple, and a string respond identically to indexing, length, and membership. They share the sequence protocol. What differs is only what they hold and whether they can change.

Intuition. Mechanism. "Sequence" isn't a vibe — it's a concrete protocol: a type is a sequence if it implements the dunder methods __getitem__ (for seq[i] and slicing), __len__, and __iter__. List, tuple, and str all implement them, so the same syntax dispatches to each. The operations live in the protocol; each type just supplies the implementation. (You'll build these protocols yourself in Dunder Methods.)

Concrete bite. This is why code written against "a sequence" transfers for free — one function works on all three:

(20, 30)
(20, 30)
('e', 'o')

One function, no type checks, works on a list, a tuple, and a string — because all three honor the indexing protocol.

2. Indexing, including negatives

Positions are zero-based: the first item is index 0. Negative indices count from the end, with -1 being the last item.

Output:

a
e
d

Analysis. seq[0] is the first element; seq[-1] is the last without needing len(seq)-1. Negative indexing is just len + index under the hood: seq[-1] means seq[len(seq)-1].

Intuition. Mechanism. There's one address space with two readings: a left ruler 0, 1, 2, … and a right ruler …, -3, -2, -1. A negative index i is resolved as len(seq) + i, so -1 lands on the last element with no len arithmetic on your part. An index outside the valid range doesn't fall back to a default — it raises.

Concrete bite. Python refuses to silently hand you nothing for a bad index (unlike a plain JavaScript array returning undefined):

Traceback (most recent call last):
  File "/w/main.py", line 2, in <module>
    print(seq[5])
          ~~~^^^
IndexError: list index out of range

The error is a feature: it turns an off-by-one into a loud failure at the point of the bug, instead of a None that propagates and explodes somewhere unrelated later.

3. Slicing — the power tool

seq[start:stop:step] returns a new sub-sequence. start is inclusive, stop is exclusive, step is the stride. Any part can be omitted.

Output:

['b', 'c', 'd']
['a', 'b']
['a', 'c', 'e']
['e', 'd', 'c', 'b', 'a']
False

Analysis. seq[1:4] takes positions 1, 2, 3 — stop=4 is excluded (this half-open convention is why len equals stop - start for a simple slice). Omitting start/stop defaults to the ends. A negative step walks backward, so seq[::-1] reverses. Critically, seq[:] builds a new list with the same elements — seq[:] is seq is False, which is why [:] is a common shallow-copy idiom.

Intuition. Mechanism. A slice never aliases — it constructs a new object and copies the selected element references into it (which is exactly why seq[:] is seq is False, connecting to the object model: a slice is a shallow copy). The half-open [start, stop) convention means seq[:k] and seq[k:] partition the sequence with no overlap and no gap, and len(seq[a:b]) == b - a for simple slices.

Concrete bite. Because a slice copies, it's the fix for the "never modify a collection while iterating it" trap. Mutating a list mid-loop makes the iterator skip elements:

[4]
[]

The first loop's iterator advances by index over a list that's shrinking underneath it, so it steps past 4 — leaving [4]. Looping over nums[:] iterates a fixed snapshot while you mutate the original safely, giving the correct [].

4. Operations every sequence shares

Concatenation, repetition, and membership work on all sequence types.

Output:

[1, 2, 3]
abcd
[0, 0, 0]
ababab
True
True

Analysis. + joins two sequences of the same type into a new one; * repeats. For strings, in tests substring containment ('b' in 'abc'), a convenient special case. All of these produce new objects.

Intuition. Mechanism. + and * build new sequences and never modify their operands. But * on a list copies references, not the underlying objects — so [obj] * 3 is three references to the same obj, not three independent copies.

Concrete bite. That reference-copying is the aliasing trap in sequence clothing:

[[1], [1], [1]]

You wanted three empty lists; you got one list pointed at three times, so appending to "row 0" appears in all of them. Safe for immutable elements ([0] * 3 is genuinely fine), dangerous for mutable ones.

5. Lists — the mutable workhorse

A list is an ordered, mutable sequence holding anything. Because it's mutable, it has in-place methods that change it and return None.

Output:

[0, 1, 2, 3, 4]
4
[0, 1, 2, 3]

Analysis. append, insert, sort, and pop mutate the list in place. Note sort() returns None (it sorts the existing list) — a classic beginner trap is lst = lst.sort(), which sets lst to None. Use sorted(lst) when you want a new sorted list and to keep the original. (Common list methods: append, extend, insert, remove, pop, sort, reverse, index, count, clear.)

Intuition. Mechanism. In-place mutators (sort, reverse, append, insert, extend) change the existing object and, by deliberate convention, return None — so there's no return value to assign. This signals "I mutated something" versus a function that "produced a new value."

Concrete bite. The convention bites when you assign the result of an in-place method:

None

[3, 1, 2].sort() sorts an anonymous list and returns None, which you then bound to lst. The sorted data is gone.

6. Tuples — the immutable record

A tuple is an ordered, immutable sequence. Same indexing/slicing as a list, but it cannot be changed after creation.

Output:

2
TypeError: 'tuple' object does not support item assignment

The single-element tuple trap — it's the comma, not the parentheses, that makes a tuple:

Output:

tuple
int

A tuple is immutable, but if it contains a mutable object, that object can still change:

Output:

([1, 2, 99], 3)

Analysis. You can't reassign a tuple's slots, but immutability is shallow: it fixes which objects the tuple holds, not the internal state of those objects. Also note (5) is just 5 in parentheses — you need the trailing comma (5,) to get a one-element tuple.

Intuition. Mechanism. What defines a tuple is the comma, not the parentheses — 1, 2, 3 is already a tuple; the parens just group it. Immutability fixes the tuple's slots (which objects it references), but is shallow — it doesn't freeze the internal state of a mutable object stored in a slot.

Concrete bite. The shallow part means a tuple can quietly become unhashable:

Traceback (most recent call last):
  File "/w/main.py", line 2, in <module>
    print(hash(key))       # cannot hash a tuple that holds a mutable list
          ~~~~^^^^^
TypeError: unhashable type: 'list'

The tuple looks immutable, but because it holds a mutable list, it can't be hashed — so it can't be a dict key or set member after all. A tuple is only fully immutable (and hashable) if everything inside it is — a fact Dictionaries & Sets leans on.

7. Strings — immutable text sequences

A string is an immutable sequence of characters. All sequence operations apply, plus a rich set of text methods that (being immutable) always return new strings.

Output:

Hello, World
a-b-c
['a', 'b', 'c']
a-b-c
2
True

Formatting with f-strings

Output:

Aniket: 3.14
   42
pi=3.14159

Analysis. split/join are inverses and the canonical way to move between strings and lists — note join is a string method called on the separator ("-".join(...)), which surprises many. f-strings embed expressions in {} with optional format specs after a colon (:.2f, :>5). The {var=} form prints both the name and value, ideal for debugging. (Strings in Depth is the full treatment.)

Intuition. Mechanism. Strings are immutable, so every "edit" (upper, replace, strip, +) leaves the original untouched and returns a new string. The crucial performance consequence: s += chunk can't extend s in place — it allocates a new string and copies all existing characters plus the new ones.

Concrete bite. That copy-per-step makes loop concatenation quadratic. This snippet processes N chunks (pieces stands for your data):

s = ""
for chunk in pieces:      # N chunks
    s += chunk            # step k copies ~k characters already accumulated

Total work is 1 + 2 + ... + N ≈ O(N²) character copies — fine at 1,000 chunks, a visible hang at 1,000,000. The list-based alternative does O(N) work:

parts = []
for chunk in pieces:
    parts.append(chunk)   # O(1) each
result = "".join(parts)   # one pass, O(N)

8. Unpacking

Sequences can be unpacked into multiple names in one assignment — a direct consequence of their ordered structure.

Output:

1
[2, 3, 4]
2 1

Analysis. first, *rest = ... binds first to the first element and *rest (a list) to everything remaining. The swap a, b = b, a works because the right side b, a first builds a tuple (2, 1), which is then unpacked into a, b — no temporary needed, and print(a, b) shows 2 1. The starred name can appear in any one position: *init, last = seq grabs the last; a, *mid, z = seq grabs the ends.

Intuition. Mechanism. Unpacking is structural assignment: the right side is (or becomes) a sequence, and Python binds its elements positionally to the names on the left. The swap works because the right side is fully evaluated into a tuple first, then unpacked. A starred name greedily absorbs the leftover middle as a list.

Concrete bite. The shape must match, or it raises — usually what you want, but it surprises people:

Traceback (most recent call last):
  File "/w/main.py", line 1, in <module>
    a, b = [1, 2, 3]      # too many values for two names
    ^^^^
ValueError: too many values to unpack (expected 2)

Three values can't bind to two names. (Use a, b, *_ = [1, 2, 3] to deliberately ignore extras, or a, *rest = ... to capture them.)

9. Complexity: what's fast, what's slow

Knowing the cost of operations is essential for real performance. For lists (dynamic arrays):

Intuition. Mechanism. A list is a contiguous array of references: element i lives at a computable offset, so indexing is O(1). But inserting or deleting anywhere except the end forces every later element to shift one slot — O(n). Membership (x in lst) has no index to exploit, so it scans linearly.

Concrete bite. The headline cost is membership inside a loop, which silently becomes quadratic. Here stream is your input of n items:

seen = []
for x in stream:            # n items
    if x in seen:           # each test scans up to n -> O(n) per item
        ...
    seen.append(x)
# total ~ O(n^2): instant for n=1,000, a hang for n=1,000,000

Swapping seen to a set makes each in O(1), collapsing the whole loop to O(n). (Full treatment in Dictionaries & Sets.)

10. Mental-model summary

Gotcha checklist

Your Turn

Before you move on, check your understanding with the coach — explain the idea, apply it, weigh the trade-offs, then defend your reasoning.