How do `re.MULTILINE` and `re.DOTALL` change what `^`, `$` and `.` match?

### The default, stated precisely With no flags, `^` matches at exactly one position: offset zero of the subject string. `$` matches at the end of the string **and** at the position just before a final newline. That second case is not a bug; it is deliberate, so that a pattern written for a line still works when the line arrives with its terminator attached. It is also the single most common surprise in this area: ```python import re re.search(r"\w+$", "abc\n").group() # 'abc' — matched, despite the newline re.search(r"abc\Z", "abc\n") # None — \Z means the true end ``` `\A` is the absolute start and `\Z` the absolute end. Unlike `^` and `$` they are unaffected by flags, and `\Z` does not forgive a trailing newline. Python has no `\z`; `\Z` already means what other flavours spell `\z`. ### re.MULTILINE `re.MULTILINE` (short alias `re.M`, inline `(?m)`) redefines the two anchors in terms of lines: `^` now matches at the start of the string and immediately after every `\n`; `$` matches at the end of the string and immediately before every `\n`. ```python text = "one\ntwo\nthree" re.findall(r"^\w+", text) # ['one'] re.findall(r"^\w+", text, re.MULTILINE) # ['one', 'two', 'three'] ``` The flag says nothing about `.`. A pattern like `^a.*b$` under MULTILINE is anchored per line *and* still cannot cross a newline, because `.` remains newline-hostile — which is usually exactly the line-oriented behaviour you wanted. ### re.DOTALL `re.DOTALL` (alias `re.S`, inline `(?s)`) does one thing: it lets `.` match `\n` too. It does not touch anchors, and it does not touch character classes — a negated class such as `[^a]` already matches a newline with or without the flag, which is why `[\s\S]` is a common flag-free way to say "any character at all". ```python re.search(r"a.b", "a\nb") # None re.search(r"a.b", "a\nb", re.DOTALL) # matches 'a\nb' ``` Combine flags with the bitwise OR: `re.MULTILINE | re.DOTALL`, or write both inline at the very start of the pattern as `(?ms)`. ### The failure this causes in production A fraud-scoring service matches rules against a free-text memo field that customers can paste multiple lines into. A rule was written as `^id=(\w+)$` and, because it never matched anything on multi-line memos, someone added `re.MULTILINE`. It matched — and now it matched *per line*. The handler had been written around `re.findall`, iterating results and enqueuing a manual-review task for each; a memo containing the same identifier on two lines produced a duplicated side effect, two review cases for one payment. At a 1,200-request-per-minute peak that turned into a visible backlog before anyone connected it to a one-word flag change. The lesson is that MULTILINE does not merely make a pattern "work on multi-line input": it changes the **cardinality** of the result. Whenever you add it, re-check every caller that assumed at most one match, and decide deliberately between three different intents: * validate the entire input → `re.fullmatch`, or anchor with `\A` and `\Z`, and do not use MULTILINE at all; * find one occurrence anywhere → `re.search` with no anchors; * process line by line → either MULTILINE with a loop that expects many matches, or, often clearer, split the text into lines yourself and match each one. That third option is worth pausing on. `for line in text.splitlines():` with an unflagged pattern is frequently more readable than a MULTILINE regular expression, because the iteration is visible in the code instead of hidden in a flag, and each match is unambiguously one line. ### Security-adjacent consequence Anchoring a validation pattern with `^...$` rather than `\A...\Z` means an attacker who can inject a newline may get a value accepted whose *first* line looks benign. `re.fullmatch(r"[A-Z]{2}-\d{4,6}", value)` is the blunt, safe formulation: it requires the whole string to match, no anchors needed, and no flag can loosen it by accident. ### What to say in an interview State the defaults first, including the trailing-newline concession that `$` makes — that detail is the tell that you have actually read the semantics. Then give one line each for the two flags, stress that they are orthogonal, and close on `\A` / `\Z` / `re.fullmatch` as the correct tools for validating a whole input. ### Picking the flag from the symptom Three symptoms map cleanly onto three fixes. A pattern that matches only the first line of a multi-line subject wants `re.MULTILINE`, or an explicit `splitlines()` loop. A pattern that stops at a newline in the middle of the region you meant to capture wants `re.DOTALL`, or a negated class such as `[\s\S]` if you would rather not change the meaning of `.` across the whole pattern. And a validation pattern that accepts a value it should have rejected usually wants neither flag — it wants `re.fullmatch`, because the real defect was `^...$` anchoring on input that could contain a newline. Naming which of the three you are looking at, before reaching for a flag, is most of the work.