What is the difference between re.match, re.search and re.fullmatch?

## The three entry points Python's `re` module exposes three functions that answer *slightly* different questions about the same pattern and string. All of them return a `re.Match` object on success and `None` on failure, and all of them are also available as methods on a compiled pattern object (`re.Pattern.match`, `re.Pattern.search`, `re.Pattern.fullmatch`). **`re.match(pattern, string)`** attempts the match **only at position 0**. It behaves as if the pattern were prefixed with a start-of-string anchor. Crucially it does *not* require the pattern to reach the end of the string: a successful `re.match` means the string **starts with** something the pattern describes. **`re.search(pattern, string)`** scans the string from left to right and returns the **leftmost** position where the pattern can match. It is the general "does this appear anywhere?" function, and it is what most people actually mean when they say "match". **`re.fullmatch(pattern, string)`** succeeds only if the pattern matches **the whole string**, start to end. It is the validation function: use it whenever you are asking "is this entire input a well-formed X?". ```python import re re.match(r"\d+", "123abc") # Match - the string starts with digits re.match(r"\d+", "abc123") # None - position 0 is not a digit re.search(r"\d+", "abc123") # Match - found at offset 3 re.fullmatch(r"\d+", "123abc") # None - trailing 'abc' is not consumed re.fullmatch(r"\d+", "123") # Match ``` ## Why the naming trips people up Two independent traps sit on the word *match*. The first is cross-language muscle memory. In several other languages a `match` method means "find occurrences anywhere", which is Python's `search`. In Python, `re.match` is the *anchored* one. Anyone arriving from another ecosystem writes `re.match(r"error", line)` expecting a scan, gets `None` for every line where the word is not first, and concludes the regex is wrong. The second is the gap between *starts with* and *equals*. `re.match` is often used for validation — "does this identifier look right?" — and it silently accepts anything with a valid prefix. A resolution string checked with `re.match(r"\d+p", value)` accepts `"720p-corrupt"`. `re.fullmatch` is the correct tool and has existed since Python 3.4; before it, people appended an end anchor by hand, which is still fine but easier to forget. ## The return value Success gives a `re.Match` object. Its most useful methods for this purpose are `Match.group()` — with no argument, the entire matched text — and the offsets: `Match.start()`, `Match.end()` and `Match.span()`, which returns the `(start, end)` pair. Failure gives `None`, so the standard shape is: ```python m = re.search(r"\d+p", "clip_1080p.mp4") if m is not None: print(m.group(), m.span()) # 1080p (5, 10) ``` Two details matter here. First, `Match` objects are **always truthy**, including a zero-length match such as `re.search(r"\d*", "abc")`, which succeeds with an empty span at offset 0. So a bare `if m:` is not *wrong*, but `if m is not None:` states the intent and survives the reader who half-remembers "empty means false". Second, you cannot chain off the call — `re.search(...).group()` raises `AttributeError: 'NoneType' object has no attribute 'group'` the moment the pattern misses, which is one of the most common tracebacks in regex-heavy code. Bind the result first, then test. ## Anchored search on a compiled pattern The method forms accept optional `pos` and `endpos` arguments — `pattern.match(string, pos)` starts the anchored attempt at that offset instead of 0. This is how you walk a string token by token without slicing it (slicing copies; `pos` does not). Note that `pos` shifts *where the attempt begins*, not what a start-of-string anchor inside the pattern means; the anchor still refers to the real beginning of the string. ## Choosing between them Ask what the question actually is: - "Is this whole value well-formed?" → `re.fullmatch`. - "Does this line contain the thing?" → `re.search`. - "Does this string begin with the thing?" → `re.match`, and consider whether `str.startswith` would be clearer and faster — for a fixed literal prefix it is both, with no pattern to escape and no engine to invoke. A useful review habit: any `re.match` in a validation path is a defect until proven otherwise. Nine times in ten it should have been `re.fullmatch`, and the tenth time it deserves a comment saying the prefix is genuinely all you care about.