Why does `a = 1000` then `b = 1000` make `a is b` True in a script but False in the REPL?

### Two separate mechanisms, one confusing symptom Pasting `a = 1000` and `b = 1000` into a file and asking whether the two names point at the same object gives `True`; typing the same two lines one at a time into the REPL gives `False`. Nothing about integers changed between the two runs — what changed is **how much source was compiled at once**. CPython compiles a whole file as a single compilation unit. While compiling, it collects the constants it sees and stores each distinct one exactly once, then hands out references to that single object wherever the literal appears — including inside functions defined in the same file. So in a script, both `a` and `b` are bound to the one `1000` object the compiler created, and the identity check reports `True`. The same is true of a whole line passed to `python -c`, of a single `exec()` of one source string, and of two statements typed on one REPL line separated by a semicolon. The REPL is different in exactly one respect: each statement you enter is compiled and executed on its own. The first line's compilation produces one `1000`; the second line's compilation has no knowledge of the first and produces another. Two objects, equal in value, distinct in identity. ### Why 256 behaves differently from 1000 Now try the same experiment with `256` typed line by line in the REPL: the answer is `True`, and with `257` it is `False`. This is the second mechanism, and it has nothing to do with compilation units. At start-up CPython preallocates one object for every integer from **-5 through 256**, and every operation that would produce one of those values — a literal, arithmetic, a parsed number — returns the preallocated object instead of allocating. The range exists because those values dominate real programs: loop counters, small lengths, flags, indices. `257` falls outside it, so each occurrence is a fresh allocation unless constant sharing happens to catch it. Since PEP 683 in **3.12**, these small integers (along with `None`, `True`, `False` and a set of statically allocated short strings) are *immortal*: their reference counts are pinned to a sentinel value and never move, which removes refcount traffic on the hottest objects in the runtime. That is an implementation detail you can observe but should not depend on. Strings show the same pair of effects. Two identical string literals inside one compilation unit are one object because of constant sharing. On top of that, a literal that looks like an identifier — only ASCII letters, digits and underscores — is put in the interpreter's intern table at compile time, so `"customer_id"` written in two different modules is one object, while `"customer id!"` written in two different modules is two. And a string built at runtime, say by joining pieces, is always a fresh object no matter how many equal strings already exist; `sys.intern()` exists precisely to collapse those. ### What to take from it The practical rule is that *equal is a language guarantee and same-object is not*. Which values are shared depends on the CPython version, on whether the code was compiled as one unit or many, on whether a value came from a literal or from computation, and on which implementation is running. Every one of the results above is reproducible on CPython 3.14 and none of them is promised by the language reference. Two habits follow. First, when a quick experiment in the REPL disagrees with what the same code does in a file, suspect the compilation unit before you suspect the values — this is the single most common cause of "it works in the shell but not in my script" identity confusion. Second, when you genuinely want one shared object — a sentinel, a canonical key, a deduplicated field name — arrange it explicitly with a module-level object or with `sys.intern()`, so the sharing is something your code guarantees rather than something the compiler happened to do for you today.