Strings and Text

Why it matters

Text is the first data almost every program touches — a filename, a user’s input, a line from a file. Getting indexing, slicing, and formatting right early avoids off-by-one bugs that otherwise resurface in every string-handling lesson from here on, and knowing where “characters” stop and “bytes” start heads off a whole class of encoding bugs before they happen.

Mental model

A str is an immutable sequence of Unicode code points — immutable meaning no method ever changes it in place; sequence meaning it supports indexing, slicing, iteration, and len(), the same shape list and tuple share.

Worked example: building a slug, safely

def slugify(title: str) -> str:
    words = title.strip().lower().split()
    cleaned = ["".join(ch for ch in word if ch.isalnum()) for word in words]
    return "-".join(word for word in cleaned if word)


def main() -> None:
    slug = slugify("  Learn Python, Deliberately!  ")
    print(f"Slug: {slug}")

    word = "café"
    print(f"'{word}' has {len(word)} characters but {len(word.encode('utf-8'))} UTF-8 bytes")


if __name__ == "__main__":
    main()

Slug: learn-python-deliberately
'café' has 4 characters but 5 UTF-8 bytes

slugify leans entirely on string methods — .strip(), .lower(), .split(), and a filtered join — rather than punctuation-matching, which is exactly the kind of task plain string methods handle cleanly. (Regular expressions exist for messier parsing problems, but reaching for one here would be solving a harder problem than this one actually is.)

The second line is the str-versus-bytes distinction made concrete: café is 4 characters — c, a, f, é are each one code point — but é alone takes 2 bytes once encoded as UTF-8, so the encoded form is 5 bytes. len() on a str always counts characters (code points); it never tells you how many bytes that text will take up once written somewhere.

Common mistakes

• Treating len(text) as “how many bytes is this” for any text that might contain accented letters, emoji, or other non-ASCII characters — encode first, then measure the bytes result if byte size is actually what you need (file sizes, network payloads, storage limits).
• Off-by-one slicing: forgetting that word[1:4] stops before index 4, not at it.
• Writing word.strip() on its own line and expecting word to have changed afterward — the return value has to be used or reassigned.

Check your understanding

Practice: warm-up

Predict len("naïve") before checking it. Is the answer 5 or 6? (The ï is a single precomposed code point here, not a base letter plus a separate combining mark — but you can’t tell that just by looking at it, which is the actual point of this exercise.)

len("naïve") -> 5

Practice: apply it

Write a small text-statistics function, text_stats(text: str) -> tuple[int, int], returning (word_count, char_count) — split on whitespace for words, and use len() for characters. Predict its output for "the quick brown fox" before running it.

Modification challenge: make text_stats also return the length of the longest word, and predict what changes if the input string has extra spaces between words (hint: .split() with no arguments already handles that case — check the reference for str if you’re not sure why).

Summary

• str is an immutable sequence of Unicode code points — slicing, indexing, and len() all work the same way they do on other sequences, but no method ever changes a string in place.
• Slices include the start index and exclude the stop index; negative indices count from the end.
• f-strings evaluate their embedded expressions immediately and support a format-spec mini-language for precision, alignment, and more — see f-strings.
• len(s) counts characters (code points), never bytes — encode explicitly (s.encode("utf-8")) whenever a byte count is what you actually need.
• Plain string methods (.strip(), .split(), .lower(), …) solve most everyday text tasks; regular expressions are a separate, more powerful tool worth reaching for only once a problem genuinely needs pattern matching, not before.