Using findall() for Pattern Matching

With findall(), capture groups identify which part of each match should be extracted.

Programming

Interactive lab

Try it: Regular expressions: a backtracking matcher

How Python's re module matches a pattern: it tries each start position, matches tokens one by one, lets greedy quantifiers take as much as possible and give it back when the rest fails (lazy ones take as little as possible), tries alternatives in order and records groups.

How it works

search tries start positions 0, 1, 2 …; match tries only position 0; findall collects every non-overlapping match.
Tokens are matched left to right: literals, ., classes like [a-c] and \d, and zero-width anchors ^, \$, \b.
A greedy quantifier (* + ? {m,n}) takes as many repetitions as it can, then backtracks one at a time; a lazy one (*? +? ??) takes as few as possible and grows only when needed.
Alternatives in a | b are tried in order; the first that lets the whole pattern match wins.
Parentheses capture the text their part matched; captures are undone when the matcher backtracks past them.

Default run (63 steps): re.search('(\\w+)@(\\w+)\\.com', 'mail bo@ikb.com now'): try each start position until one matches. … re.search('(\\w+)@(\\w+)\\.com', 'mail bo@ikb.com now') → <re.Match object; span=(5, 15), match='bo@ikb.com'>

Simplified: A subset of re: no flags, lookarounds, backreferences, named groups or possessive quantifiers; pattern and text up to 24 printable ASCII characters. The trace stops after 1900 attempts ("too many steps") where real Python would keep backtracking.

Educational simulation

Loading the simulation…

Why Extraction Needs a Pattern

Structured text often contains values surrounded by labels, separators, or other fields. A first approach is to split the text at spaces, commas, or other delimiters and then select a position. That approach is simple, but it depends on the input keeping exactly the same formatting and field order. If spacing or labels change, the selected position may no longer contain the intended value. Regular expressions provide a more flexible way to describe the structure you want to find. With findall(), capture groups identify which part of each match should be extracted.

Tracing a Numeric Match

Code walkthrough

import re

text = "score=84"
values = re.findall(r"^score=([0-9]+)$", text)
print(values)

1
The input is score=84.
2
The anchored pattern checks the complete line rather than looking for an unrelated occurrence inside a larger string.
3
The capture group matches 84.
4
findall() extracts the captured value, so the result contains 84 rather than the full text score=84.

The caret requires the match to begin at the start of the line.
score= matches the literal label and separator.
The parentheses form a capture group.
[0-9]+ matches one or more numeric characters.
The dollar sign requires the match to reach the end of the line.

Output

["84"]

How do anchors identify the complete line, and which group becomes the extracted number?

The parentheses are not merely visual grouping. They define the capture group, which tells findall() to return the numeric portion instead of the entire matched line. The caret and dollar sign act as anchors. Together, they require the input to follow the described line format from beginning to end. This prevents a pattern from accepting a valid-looking fragment inside malformed data.

Greedy Match Boundaries

Quantifiers determine how much input a pattern attempts to consume. The quantifiers [0-9]+ and .* are greedy: they consume as much as possible before the rest of the pattern is checked. If the remaining pattern cannot match after that first attempt, the greedy part backtracks and gives characters back until the rest can match. This behavior is predictable, but it can produce an unexpectedly broad capture when the pattern does not include a precise boundary.

python

import re

text = "record=42;status=ready"
values = re.findall(r"record=(.*)", text)
print(values)

import re

text = "record=42;status=ready"
values = re.findall(r"record=(.*)", text)
print(values)

Output

["42;status=ready"]

Here, .* is allowed to consume the remaining text, so the captured value includes both the number and the later status field. The pattern has no boundary telling the greedy part to stop before the semicolon. A more specific pattern can describe the numeric field directly, such as [0-9]+, or can place a required trailing part after a greedy expression so that backtracking establishes the boundary.

How far does a greedy expression extend when the pattern gives it no earlier stopping boundary?

Multiple Values in Order

python

import re

text = "score=84 score=91 score=76"
values = re.findall(r"score=([0-9]+)", text)
print(values)

import re

text = "score=84 score=91 score=76"
values = re.findall(r"score=([0-9]+)", text)
print(values)

Output

["84", "91", "76"]

The pattern describes a score label followed by one or more digits, while the parentheses identify the digits as the extracted portion. findall() applies the pattern across the input and produces the captured values in the order in which the matching score fields occur. The returned values are the text matched by the capture group, not the surrounding score= label.

Worked example

Extracting a Complete Numeric Field

Extract the number from the structured line score=84, while rejecting a line with extra trailing text.

1
Describe the label
Use score= to require the expected field name and separator.
2
Capture digits
Place [0-9]+ inside parentheses so the numeric portion is the part extracted by findall().
3
Anchor the format
Place ^ at the beginning and $ at the end so the complete line must follow the pattern.
4
Trace the result
For score=84, the capture group contains 84. For score=84 extra, the end anchor prevents the complete pattern from matching.

Result

The pattern ^score=([0-9]+)$ extracts the intended number only when the complete line has the expected format.

Debugging Failed Matches

When extraction fails, do not begin by changing several parts of the pattern at once. Trace the match from left to right against the actual input. Check where the pattern begins, which literal characters match, how many characters a quantifier consumes, and whether the final anchor can still match. A failure at the end often means the input contains an extra character or field that the anchored pattern does not permit.

Before

pattern = r"^score=([0-9]+)$"
text = "score=84 points"

The digit group matches 84, but the end anchor is reached while points remains.

After

pattern = r"^score=([0-9]+) points$"
text = "score=84 points"

The pattern describes the trailing field, so the complete line can match.

Which characters does each part consume, where does the match stop, and why does the original pattern fail?

1
Write down the exact input, including spaces, punctuation, labels, and trailing text.
2
Mark the start and end positions required by any anchors.
3
Trace each literal part of the pattern across the input.
4
Trace each quantifier and note whether it consumes more characters than intended.
5
Check whether every remaining pattern component can match after the quantifier stops.
6
Inspect the capture group separately from the full match.

Regex or String Splitting

Approach	What it assumes	Main risk
String splitting	Delimiters, spacing, and field positions remain consistent	A formatting change can move the desired value to a different position and requires additional error handling
Regex with findall()	The input follows the structure described by the pattern	An imprecise pattern can capture too much or accept an unintended fragment

Both approaches depend on assumptions, but regex can express labels, numeric forms, anchors, and capture boundaries together.

String splitting is not automatically wrong. It is useful when the format is simple and controlled. It becomes brittle when the input may contain changed spacing, altered labels, additional fields, or a different field order. A regular expression can describe the meaningful structure instead of relying only on a value's position after splitting. Anchors and specific quantifiers make that description more precise, while capture groups identify the result to extract.

Common Extraction Mistakes

Common mistake
Matching the whole line without a capture group
What it looks like
```
pattern = r"^score=[0-9]+$"
```
Why it fails
The pattern describes the line, but no parentheses identify the numeric part for extraction.
Do this instead
Use pattern = r"^score=([0-9]+)$" when the number is the desired result.
Common mistake
Omitting anchors when the complete format matters
What it looks like
```
pattern = r"score=([0-9]+)"
```
Why it fails
The pattern can match the score fragment even when additional text makes the line malformed for the intended format.
Do this instead
Use ^ and $ when the whole line must follow the specified structure.
Common mistake
Using a greedy wildcard for a narrow numeric field
What it looks like
```
pattern = r"record=(.*)"
```
Why it fails
The wildcard can consume later labels and values, producing a capture wider than the intended field.
Do this instead
Use a numeric quantifier such as [0-9]+ when the field is numeric, or provide a precise trailing boundary.
Common mistake
Assuming a failed extraction means the number is absent
What it looks like
```
text = "score=84 points" with pattern r"^score=([0-9]+)$"
```
Why it fails
The numeric part can match while the end anchor fails because extra text remains.
Do this instead
Trace the unmatched characters and decide whether the pattern should reject them or describe them explicitly.

Practice the Trace

MEDIUM

Consider the input text record=17;status=ready and the pattern record=([0-9]+). Predict the extracted value. Then explain what would change if the pattern used record=(.*) instead.

Hints

Locate the capture group in each pattern.
Ask which characters [0-9]+ is allowed to consume.
Ask how far .* can extend when no later boundary is required.

Your attempt (not saved)

What do you think happens?

What does the capture group in record=([0-9]+) match within record=17;status=ready?

record=17
17
17;status=ready
Nothing, because the semicolon appears

Reveal answer

Answer:

The capture group contains [0-9]+, so it consumes the consecutive numeric characters after record=. The semicolon is outside that numeric group.

Key Takeaways

1
Use parentheses to tell findall() which part of a match to extract.
2
Use ^ and $ when the complete line format must be validated.
3
Remember that [0-9]+ and .* are greedy and may consume more input before backtracking.
4
Debug failures by tracing each pattern component against the actual characters in the input.
5
Regex extraction is often more flexible and maintainable than position-based string splitting, but the pattern still needs precise boundaries.

At a glance

Capture groups determine which portion of each regex match findall() extracts.
Anchors constrain a pattern to the beginning and end of the intended line format.
Greedy quantifiers consume as much as possible and backtrack when later pattern parts need space to match.
Tracing the pattern against real input reveals whether a failure comes from an anchor, a literal, a quantifier, or an unexpected delimiter.
Regex can describe structured fields more flexibly than brittle string-splitting logic.

Related concepts

More concepts starting with U

Try it: Regular expressions: a backtracking matcher

Why Extraction Needs a Pattern

Tracing a Numeric Match

Greedy Match Boundaries

Multiple Values in Order

Debugging Failed Matches

Regex or String Splitting

Common Extraction Mistakes

Practice the Trace

Key Takeaways

At a glance

Related Topics

Related concepts