Python Strings: A Practical Guide to Slicing, Formatting, and Encoding

You reach for a string every time data arrives as text instead of numbers — a name typed into a form, a line from a log file, a row copied out of a spreadsheet. The question you’re actually asking is rarely “what is a string,” it’s “how do I get from this messy text to the clean value I need.” Python’s str type answers that question with a long list of built-in methods, and most of the confusion people run into isn’t any one method being hard — it’s not having a model for how the pieces fit together.

That’s also where people quietly get stuck: strings look mutable because .replace() and .upper() seem to “change” them, slicing syntax has more moving parts than list indexing lets on, and f-string format specs fail silently instead of raising an error when you get them slightly wrong. (Once plain string methods stop being enough — because you need to match a shape of text rather than exact characters — our post on Python regex for data analysis is the natural next step.) This guide keeps things focused: one mental model, then indexing and slicing, cleanup methods, f-string formatting, and just enough encoding to keep a UnicodeDecodeError from ruining your afternoon.

The Mental Model: A Sequence That Never Changes

Two ideas cover almost everything a str does:

1. A string is an immutable, ordered sequence of characters. Every character has a position — an index — counting up from 0 at the start and down from -1 at the end. You can read any character or any slice of characters by position, but you can never assign a new one into place.
2. Every string method either asks a question or makes a brand-new string. Methods like .startswith() or .find() inspect the string and hand back an answer (a bool, an int). Methods like .replace() or .upper() look like they’re editing the string, but they always return a new string — the original object is untouched.

Keep both in mind and most string bugs stop being surprising: a “mutation” that didn’t stick is an unassigned return value, and an off-by-one slice is an index counted from the wrong end.

badge = "LOOPCITY-2026-014"
new_badge = badge.replace("014", "015")
print(badge)
print(new_badge)
print(badge is new_badge)

LOOPCITY-2026-014
LOOPCITY-2026-015
False

.replace() didn’t touch badge — it built and returned a different string object, which is why badge is new_badge comes back False. Skip capturing the return value, and the “change” is silently thrown away.

Signups You Can Reproduce

Imagine you’re running registration for Loop City, a one-day, in-person Python workshop. Attendees fill out a paper signup slip at the door, and whoever’s at the table types each slip into a spreadsheet as one comma-separated line — by hand, at different speeds, with different habits about spacing and capitalization:

raw_signups = [
    "  Maria García , [email protected] , Berlin , 2 ",
    "Lars Møller,[email protected],Copenhagen,1",
    " Amélie Dubois ,[email protected], Paris ,3",
    "Yuki Tanaka, [email protected],Tokyo,1",
    "  Søren Holm , [email protected],Copenhagen , 2  ",
]
for line in raw_signups:
    print(repr(line))

'  Maria García , [email protected] , Berlin , 2 '
'Lars Møller,[email protected],Copenhagen,1'
' Amélie Dubois ,[email protected], Paris ,3'
'Yuki Tanaka, [email protected],Tokyo,1'
'  Søren Holm , [email protected],Copenhagen , 2  '

Five rows: name, email, city, ticket_count. Notice the inconsistent whitespace, the shouted email on row one, and a typo domain on row four (exmaple.com) — every one of those is a real thing a hand-typed spreadsheet produces, and every one of them is fixable with a handful of string methods. (The outputs in this post come from Python 3.11 — everything shown also works on Python 3.9+.)

Indexing and Slicing Reveal the Shape of a String

Each attendee gets a badge whose prefix is the event code. Indexing and slicing are how you read pieces of a string by position instead of by content:

event = "LOOPCITY"
print(len(event))
print(event[0], event[-1])
print(event[2:5])
print(event[-3:])
print(event[::-1])

8
L Y
OPC
ITY
YTICPOOL

event[0] counts from the front, event[-1] counts from the back — Python never makes you compute len(event) - 1 yourself. A slice event[2:5] reads “start at index 2, stop before index 5,” which is why it returns three characters (2, 3, 4), not four. event[-3:] reads “from three characters before the end to the end,” and event[::-1] — an empty start, empty stop, and a step of -1 — walks the whole string backward.

The full badge code follows the pattern EVENT-YEAR-SEQ, so slicing it apart is one line each:

badge = "LOOPCITY-2026-014"
print(len(badge))
print(badge[:8])
print(badge[9:13])
print(badge[14:])

17
LOOPCITY
2026
014

And immutability isn’t just a description — Python enforces it. Trying to assign a new character into a specific index fails loudly:

try:
    event[0] = "l"
except TypeError as exc:
    print(f"TypeError: {exc}")

TypeError: 'str' object does not support item assignment

A list would happily accept some_list[0] = "l". A str refuses outright — if you want a modified version, you build a new string and assign it to a variable, which is exactly what .replace() did above. The official Python string methods reference documents every method mentioned in this post and dozens more.

Trimming and Splitting Raw Rows

Each raw line is one string with commas inside it. .split(",") breaks it into a list of pieces, and .strip() removes the leading and trailing whitespace each piece picked up from the hand-typed spreadsheet:

first_row = raw_signups[0]
fields = [field.strip() for field in first_row.split(",")]
print(fields)

['Maria García', '[email protected]', 'Berlin', '2']

Run the same two-method combination over every row, and unpack the four fields straight into names on the way in:

parsed = []
for line in raw_signups:
    name, email, city, tickets = (field.strip() for field in line.split(","))
    parsed.append({"name": name, "email": email, "city": city, "tickets": int(tickets)})
for row in parsed:
    print(row)

{'name': 'Maria García', 'email': '[email protected]', 'city': 'Berlin', 'tickets': 2}
{'name': 'Lars Møller', 'email': '[email protected]', 'city': 'Copenhagen', 'tickets': 1}
{'name': 'Amélie Dubois', 'email': '[email protected]', 'city': 'Paris', 'tickets': 3}
{'name': 'Yuki Tanaka', 'email': '[email protected]', 'city': 'Tokyo', 'tickets': 1}
{'name': 'Søren Holm', 'email': '[email protected]', 'city': 'Copenhagen', 'tickets': 2}

tickets gets converted to an int right here, because .split() and .strip() only ever produce strings. .split() turns one string into several; "separator".join(...), used below, turns several back into one.

Normalizing Case and Fixing a Typo

Two rows sneak past .strip() uncleaned: row one’s email is shouting in uppercase, and row four’s domain has a typo. Case methods and .replace() handle both:

for row in parsed:
    row["email"] = row["email"].lower()
    row["city"] = row["city"].title()
for row in parsed:
    print(row)

{'name': 'Maria García', 'email': '[email protected]', 'city': 'Berlin', 'tickets': 2}
{'name': 'Lars Møller', 'email': '[email protected]', 'city': 'Copenhagen', 'tickets': 1}
{'name': 'Amélie Dubois', 'email': '[email protected]', 'city': 'Paris', 'tickets': 3}
{'name': 'Yuki Tanaka', 'email': '[email protected]', 'city': 'Tokyo', 'tickets': 1}
{'name': 'Søren Holm', 'email': '[email protected]', 'city': 'Copenhagen', 'tickets': 2}

.lower() makes every email comparable regardless of how it was typed, and .title() capitalizes each word of the city — harmless here since every city in this batch is one word. The typo domain survives case normalization because exmaple.com is already lowercase; fixing it is a job for .replace(), once you’ve located it:

sample_email = parsed[0]["email"]
at_pos = sample_email.find("@")
print(sample_email, at_pos, sample_email[:at_pos], sample_email[at_pos + 1:])

before = parsed[3]["email"]
fixed = before.replace("exmaple.com", "example.com")
parsed[3]["email"] = fixed
print(before, "->", fixed)

[email protected] 12 maria.garcia example.com
[email protected] -> [email protected]

.find("@") returns the position of the @ character, which is what makes slicing the email into a local part and a domain possible. .replace() swaps every occurrence of one substring for another and, like every method in this section, returns a new string rather than editing in place.

Rebuilding Clean Lines with .join()

Once every field is clean, you often want the row back as one string — a normalized line to write out, or a key for deduplication. str.join() is the reverse of .split(): call it on the separator, and pass it the list of pieces to glue together:

clean_lines = [
    ", ".join([row["name"], row["email"], row["city"], str(row["tickets"])])
    for row in parsed
]
for line in clean_lines:
    print(line)

Maria García, [email protected], Berlin, 2
Lars Møller, [email protected], Copenhagen, 1
Amélie Dubois, [email protected], Paris, 3
Yuki Tanaka, [email protected], Tokyo, 1
Søren Holm, [email protected], Copenhagen, 2

Every row now uses one consistent format. str(row["tickets"]) is required because .join() only accepts a list of strings — it won’t silently convert the integer for you.

Formatting a Report with f-Strings

Registration data is more useful as a report than as a list of dicts. An f-string embeds an expression directly inside a string literal, and everything after a : inside the braces is a format spec — alignment, width, and precision, all in one place:

TICKET_PRICE = 145
print(f"{'Name':<15} {'City':<12} {'Tickets':>7} {'Revenue':>10}")
total_tickets = 0
total_revenue = 0.0
for row in parsed:
    revenue = row["tickets"] * TICKET_PRICE
    total_tickets += row["tickets"]
    total_revenue += revenue
    print(f"{row['name']:<15} {row['city']:<12} {row['tickets']:>7} {revenue:>10,.2f}")
print(f"{'TOTAL':<15} {'':<12} {total_tickets:>7} {total_revenue:>10,.2f}")

Name            City         Tickets    Revenue
Maria García    Berlin             2     290.00
Lars Møller     Copenhagen         1     145.00
Amélie Dubois   Paris              3     435.00
Yuki Tanaka     Tokyo              1     145.00
Søren Holm      Copenhagen         2     290.00
TOTAL                              9   1,305.00

<15 left-aligns within a 15-character field, >7 right-aligns within 7 — text conventionally goes left, numbers right. >10,.2f does three things at once: right-align in 10 characters, insert a , thousands separator, and show exactly 2 decimal places. That comma in 1,305.00 isn’t in the underlying number — Python only adds it because the format spec asked for it.

The same width trick zero-pads badge numbers for the next print run:

for i, row in enumerate(parsed, start=1):
    print(f"LOOPCITY-2026-{i:03d}  {row['name']}")

LOOPCITY-2026-001  Maria García
LOOPCITY-2026-002  Lars Møller
LOOPCITY-2026-003  Amélie Dubois
LOOPCITY-2026-004  Yuki Tanaka
LOOPCITY-2026-005  Søren Holm

03d means “integer, zero-padded, at least 3 digits wide” — attendee 1 becomes 001, matching the sequence style from the badge code sliced apart earlier.

Saving and Reading Text Safely

A str in Python is already Unicode — it can hold í, ø, €, or an emoji without any special handling. Files and network connections, though, only understand raw bytes, so writing text to disk means converting it, and reading it back means converting in the other direction. .encode() turns a str into bytes:

name = parsed[0]["name"]
utf8_bytes = name.encode("utf-8")
print(name)
print(utf8_bytes)
print(len(name), "characters", len(utf8_bytes), "bytes")
print(type(name), type(utf8_bytes))

Maria García
b'Maria Garc\xc3\xada'
12 characters 13 bytes
<class 'str'> <class 'bytes'>

"Maria García" is 12 characters, but 13 bytes — the accented í takes two bytes in UTF-8 (\xc3\xad), while every plain ASCII character takes one. Writing and reading a file works the same way, just with pathlib or open() doing the encode/decode for you as long as you tell it which encoding to use:

import pathlib
report_path = pathlib.Path("loopcity_report.txt")
lines_out = [f"{row['name']}, {row['city']}, {row['tickets']}" for row in parsed]
report_path.write_text("\n".join(lines_out), encoding="utf-8")
round_tripped = report_path.read_text(encoding="utf-8")
print(round_tripped)

Maria García, Berlin, 2
Lars Møller, Copenhagen, 1
Amélie Dubois, Paris, 3
Yuki Tanaka, Tokyo, 1
Søren Holm, Copenhagen, 2

Writing and reading with the same encoding round-trips perfectly, accents and all. The trouble starts when those two encodings disagree — which is exactly the next section.

Four Gotchas Worth Knowing

.find() returns -1 on failure; .index() raises ValueError. They look interchangeable — both locate a substring — but they fail in opposite ways, and using the wrong one for the job either crashes your program or lets a bad value sneak through silently:

missing = "no-at-sign-here"
print(missing.find("@"))
try:
    missing.index("@")
except ValueError as exc:
    print(f"ValueError: {exc}")

-1
ValueError: substring not found

Use .find() when “not found” is a normal outcome you plan to check for. Use .index() when a missing substring means something is actually wrong and the program should stop.

String concatenation in a loop is O(n²); building a list and calling .join() scales linearly. Every s += "x" can force Python to copy everything accumulated so far into a new string, so the cost of the whole loop grows faster than the number of characters you’re adding:

import timeit

def build_with_plus(n):
    s = ""
    for _ in range(n):
        s += "x"
    return s

def build_with_join(n):
    return "".join("x" for _ in range(n))

for n in (1_000, 5_000, 20_000):
    t_plus = timeit.timeit(lambda: build_with_plus(n), number=20)
    t_join = timeit.timeit(lambda: build_with_join(n), number=20)
    print(f"n={n:>6}  += : {t_plus:.4f}s   join: {t_join:.4f}s   ratio: {t_plus / t_join:.1f}x")

n=  1000  += : 0.0010s   join: 0.0010s   ratio: 1.0x
n=  5000  += : 0.0057s   join: 0.0045s   ratio: 1.3x
n= 20000  += : 0.0235s   join: 0.0170s   ratio: 1.4x

Modern CPython optimizes the common case of s += x in a loop, so the gap is modest here rather than dramatic — but it still grows as n grows, and gets worse at real log-file scale. .join() is never worse, so it’s the safer default.

A format-spec typo can silently produce the wrong output instead of an error. Meaning to write .2f (2 decimal places) but dropping the dot leaves 2f, which Python parses as a perfectly valid — but completely different — spec: width 2, type f (float, defaulting to 6 decimal places):

price = 3.14159
print(f"{price:.2f}")
print(f"{price:2f}")

3.14
3.141590

No exception, no warning — just six decimal places where you expected two. A missing . is one of the easiest typos to miss on review.

Writing UTF-8 and reading it back as ASCII raises a real UnicodeDecodeError. This is the encoding mismatch the round-trip above was quietly set up to avoid — do it wrong, and Python refuses the bytes it can’t interpret rather than guessing:

try:
    report_path.read_text(encoding="ascii")
except UnicodeDecodeError as exc:
    print(f"UnicodeDecodeError: {exc}")
report_path.unlink()

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10: ordinal not in range(128)

The error names the exact byte and position that broke — 0xc3 is the first byte of í’s two-byte UTF-8 encoding, and ASCII has no idea what to do with it. The fix is almost never “strip the accents”: it’s matching the encoding you read with to the encoding you wrote with, which for new code should be utf-8.

Wrapping Up

Every method in this post is either answering a question about a string or building a new one — the string you started with never changes underneath you:

• Indexing and slicing ([]) → read characters or ranges by position, counting from 0 forward or -1 backward
• .strip() / .split() / .join() → trim whitespace, break one string into many, glue many back into one
• .lower() / .title() / .replace() → normalize case, swap substrings — all return new strings
• .find() vs .index() → the same lookup, opposite failure behavior: -1 versus ValueError
• f-strings and format specs → alignment (<, >), padding (03d), precision and thousands separators (,.2f), all inside {value:spec}
• .encode() / .decode() → the bridge between str (Unicode text) and bytes (what files and networks actually store)

If you want to build these fundamentals into a fuller Python foundation — variables, data types, and the rest of the core language before moving into data analytics — Lesson 2: Variables and Data Types in our free Python for Data Analytics course covers where strings fit alongside numbers and booleans from the very start.