Which strings does CPython intern automatically, and what does `sys.intern` do?

### What interning is Interning is the technique of keeping exactly one canonical object per distinct value, in a table the runtime consults whenever it needs that value. Because Python strings are immutable, sharing is always safe: nobody can mutate the shared copy out from under another holder. CPython uses interning for two concrete wins — memory, when the same text appears thousands of times, and speed, because comparing two interned strings can stop at a pointer comparison. ### What CPython interns without being asked The compiler interns string constants in the code it produces when the text looks like an identifier: only ASCII letters, digits and underscores. `"total"` is interned; `"clinical lab"`, with its space, is not. Beyond constants, the runtime interns the strings it uses structurally: variable, function, class, module and attribute names, and the keys those names become in module and class dictionaries. Single-character latin-1 strings and the empty string are also cached objects. That set is chosen because attribute lookup and namespace lookup are the hottest string-keyed operations in the interpreter, and they benefit most from pointer-equality fast paths. Everything built at run time is outside that set. `" ".join(parts)`, `text[4:9]`, `bytes.decode`, `str.format`, an f-string, a line read from a file — each produces a fresh object even when an equal string already exists. This is exactly why identity comparisons on parsed data behave differently from identity comparisons on literals. ### `sys.intern` `sys.intern(s)` takes a `str`, ensures the intern table holds a canonical object for that value, and **returns** it. Two properties trip people up. First, it does not modify the argument: `sys.intern(a)` leaves `a` alone, so you must bind the result. Second, it is only useful if you route *every* copy through it — interning one of two equal strings does nothing for identity between them. ```python import sys a = "clinical lab" b = " ".join(["clinical", "lab"]) print(a is b) # False print(sys.intern(a) is sys.intern(b)) # True print(a == b) # True regardless ``` ### When deliberate interning pays The classic case is bulk parsing where a small vocabulary repeats enormously: status codes, column names, units, category labels, panel names. A loader that reads millions of records will otherwise hold millions of separate objects for a few dozen distinct strings. Interning those fields as they are parsed collapses them to one object each, cutting resident memory and making the dictionaries keyed by them faster, because a hit can be decided by comparing pointers instead of walking characters. The opposite case is a caution: interning high-cardinality values — patient identifiers, request ids, free text — puts unbounded distinct strings into a table that CPython treats as long-lived. Since 3.12, PEP 683 made interned strings immortal objects, so you should not assume their memory is promptly reclaimed. Intern low-cardinality, high-repetition fields only. ### What interning does not do It does not change equality. `==` compares values and is unaffected. It does not make `is` a valid way to compare strings: the moment one side comes from a source you do not control, or from a code path that builds it at run time, identity fails while equality still holds. Interning is a performance tool, and any correctness that appears to follow from it is coincidence. CPython warns you about the most visible form of that mistake — writing `is` against a string literal produces a `SyntaxWarning` at compile time naming the literal type and suggesting `==`. ### Interviewer's angle What is being tested is whether you know *which* strings share an object and why, rather than whether you can recite that interning exists. A strong answer names the identifier-like rule for compile-time constants, points out that run-time construction escapes it, describes `sys.intern` as returning the canonical object rather than mutating anything, gives the duplicate-heavy parsing use case, and closes by refusing to treat any of it as a correctness guarantee.